RE: Addition of CmdSN in Data-out PDU

["Eddy Quicksall" <Eddy_Quicksall@ivivity.com>]

Thanks,

Now I see your point.

Eddy

-----Original Message-----
From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
Sent: Thursday, October 11, 2001 12:21 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Subject: Re: Addition of CmdSN in Data-out PDU



Eddy,

I was referring to Sec 2.2.5

   Unsolicited data MUST be sent on every connection in the 
   same order in which commands were sent

-Sandeep

Eddy Quicksall wrote:
> 
> You can't assume the ITT takes a specific order.
> 
> Eddy
> 
> -----Original Message-----
> From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
> Sent: Thursday, October 11, 2001 10:30 AM
> To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Cc: 'Paul Koning'; ips@ece.cmu.edu
> Subject: Re: Addition of CmdSN in Data-out PDU
> 
> If we use the fact that the ITT-ordering of the unsolicited
> Data-out PDUs is identical to the ITT-ordering of the commands
> sent *within* a connection, then it should be possible to
> resolve the Data-out PDUs in a constant-time operation[*1]
> No hash and no cmdSN is required keep a per-connection
> chain within the command queue and look at its head.
> 
> [*1]There are a couple of exceptions, due to the leeway the
>     standard provides the initiator on Data-out PDUs.
> 
> -Sandeep
> 
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> >
> > Since I started this thread I feel I must at least contribute!
> >
> > The reason why I proposed putting CmdSN (actually it should be
> RefCmdSN) in
> > the Data-out PDUs was to enable the target to have a faster search
to
> > associate unsolicited data out PDUs with its SCSI Command PDU.
> Solicited
> > Data-out PDUs do not require this as they have a Target Task Tag.
> >
> > If all Command PDUs were queued then I believe this would work just
> fine.
> > However, as Santosh correctly pointed out they are not and without
> repeating
> > what he said this mechanism would not work for immediate command
PDUs.
> >
> > I am sure that particular implementations could make this work but
the
> > underlying argument is that it needs to work and be useful to all
> > implementations.  The only benefit I now see of having CmdSN in the
> data PDU
> > is as a check as implementations must (and can only) use the
initiator
> task
> > tag to associated the Data-out PDU with the command PDU.  Therefore,
> IMO it
> > is not a good enough reason for having CmdSN in the Data-out PDUs
> simply for
> > a consistency check.
> >
> > The benefit of having the data sent unsolicited to minimise if not
> eradicate
> > round trip times far out weighs the overhead in having to perform a
> search
> > on receipt of unsolicited data. If we could have developed a well
> defined
> > mechanism to overcome this overhead then all well and good and that
is
> what
> > I attempted.  Still, if someone can do this and the solution is
simple
> and
> > straight forward then I am sure that it will have my backing but
until
> then
> > ...
> >
> > Cheers
> >
> > Matthew Burbridge
> > Senior Development Engineer
> > NIS-Bristol
> > Hewlett Packard
> > Telnet: 312 7010
> > E-mail: matthewb@bri.hp.com
> >
> >
> > -----Original Message-----
> > From: Paul Koning [mailto:pkoning@jlc.net]
> > Sent: Wednesday, October 10, 2001 5:07 PM
> > To: Julian_Satran@il.ibm.com
> > Cc: ips@ece.cmu.edu
> > Subject: Re: Addition of CmdSN in Data-out PDU
> >
> > Excerpt of message (sent 10 October 2001) by Julian Satran:
> > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be
> reused, it
> > > may have large holes and using it in an implementation is as bad
as
> a
> > > hashed index.
> >
> > Not true.
> >
> > CmdSN values are sequential, by definition.  Yes, clearly there will
> > be small holes because commands complete out of order.  But "large"
> > holes are unlikely.
> >
> > In any case, the target has control over that.  I can use an array
> > whose size is given by the number of pending commands times a
> > correction factor to account for the likely density of holes.  Then
> > MaxCmdSN would be updated based on two considerations: the ability
to
> > handle more pending commands, and the need to keep the distance
> > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by
the
> > size of the lookup array.
> >
> > So having CmdSN in the DataOut PDU allows this approach, thereby
> > replacing a hash lookup on a rapidly changing ID space by a simple
> > array indexing operation.  Without CmdSN, you're forced to use a
> > mechanism that has a lot more overhead (in the insert/remove or in
the
> > lookup, depending on the mechanism chosen).
> >
> >         paul