Re: Addition of CmdSN in Data-out PDU

[andy currid <andy@windriver.com>]

Santosh

Thanks for pointing this out, I'd overlooked the immediate
command case. I agree, this breaks the current proposal.

Andy


> Andy, Paul & All,
> 
> The proposed model is broken if an initiator issues a few immediate scsi
> commands. (such cmds will share the same cmdsn, that of the last issued
> non-immediate cmdsn).
> 
> The only unique identifier is the initiator task tag in the case of
> un-solicited I/O.
> 
> Thanks,
> Santosh
> 
> 
> Paul Koning wrote:
>> 
>> Excerpt of message (sent 9 October 2001) by andy currid:
>>>
>>> Julian, all
>>>
>>> I second Matthew's request to have CmdSN present in DataOut PDUs.
>>> ...
>>> When receiving unsolicited DataOut PDUs, a target must currently use
>>> the ITT to determine the command with which the DataOut is associated.
>>> In the absence of hardware assist such as a CAM, a target implementation
>>> must search a list of non-final commands currently queued within the
>>> session to match the ITT. When many such commands are queued (which ought
>>> to be the case for performant implementations), that search will relatively
>>> inefficient, no matter how the search is optimized (binary search, hash
>>> table, etc.).
>> 
>> I'll add my voice to the set.  Andy's arguments make perfect sense.
>> Lookups on unstructured IDs are a pain.  Hashing can be fast, but hash
>> table changes typically aren't.  The nasty case is a lookup on a set
>> of unstructured IDs that changes very rapidly, which is exactly the
>> case we have here.
>> 
>>> Placing CmdSn in DataOut will allow a target to instantly access the
>>> queued command with which an unsolicited DataOut is associated, without
>>> performing a search. Mapping from a CmdSN into a queue location within
>>> the target is almost certainly a constant time operation.
>> 
>> Exactly.
>> 
>>> I don't see any performance issues with making this change. I don't
>>> think it's a big imposition on an initiator to include the associated
>>> CmdSN in a DataOut PDU. Do any initiator implementors feel this would
>>> be a problem?
>>>
>>> On the target end, I don't think consistency checking is an issue. In a
>>> solicited data out carrying CmdSN, targets would be free to ignore CmdSN
>>> and simply use TTT as they do today. There's no obligation to verify
>>> CmdSN is consistent with the DataOut's associated command, though such
>>> a check is likely to be cheap.
>> 
>> Consistency checking could be left out entirely if we wish.  That
>> would be my inclination.  Or it could be made optional -- or even, if
>> people insist, mandatory.  It's very cheap if that's done.  The
>> response to an inconsistency should be harsh (terminate the session,
>> for example) because it will only happen if the sender is defective.
>> 
>>      paul


--
Andy Currid                                       andy@windriver.com
Server Products Group                       http://www.windriver.com
Wind River Networks                         Phone : (1) 510 749 2191
500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560