RE: Addition of CmdSN in Data-out PDU

["Deva-Adaptec" <deva@platys.com>]

I agree with the reasons cited by Julian and  Santosh. I think that it is not a good idea to use cmdSN in the data pdus.

 

Deva

Adaptec

 

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Tuesday, October 09, 2001 2:45 PM
To: ips@ece.cmu.edu
Subject: Re: Addition of CmdSN in Data-out PDU

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.
I you want to pursue this please forward a draft showing what the distinct application advantages are to the list.
It can include pseudo-code, flowcharts or whatever else you think that you need to convince the list.

Julo

Paul Koning <pkoning@jlc.net> 09-10-01 21:59 Please respond to Paul Koning

To:        andy@windriver.com         cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu         Subject:        Re: Addition of CmdSN in Data-out PDU

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