Subject: Re: Addition of CmdSN in Data-out PDU

From: "Julian Satran" <[email-masked]>
Date: Wed, 10 Oct 2001 00:45:24 +0300

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 <[email-masked]>
09-10-01 21:59
Please respond to Paul Koning

        To:     [email-masked]
        cc:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        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

---

From: "Deva-Adaptec" <[email-masked]>
Date: Tue, 9 Oct 2001 18:58:56 -0700

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
  Sent: Tuesday, October 09, 2001 2:45 PM
  To: [email-masked]
  Subject: Re: Addition of CmdSN in Data-out PDU

may have large holes and using it in an implementation is as bad as a hashed
index.

  Julo

                To:        [email-masked]

ought
relatively

  Exactly.

      paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 10 Oct 2001 12:06:30 -0400

> may have large holes and using it in an implementation is as bad as a 

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