RE: Addition of CmdSN in Data-out PDU

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

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