Re: Addition of CmdSN in Data-out PDU

[Paul Koning <pkoning@jlc.net>]

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