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

From: "Julian Satran" <[email-masked]>
Date: Tue, 9 Oct 2001 16:25:40 +0300

Matthew,

As a basic rule we tried to avoid having fields that have to be checked 
for consistency by the reciver whenever we could.
Can you be more explicit and help convince us and many others that we 
should make an exception here.

Regards,
Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
08-10-01 12:30
Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

        To:     [email-masked], Julian Satran/Haifa/IBM@IBMIL
        cc: 
        Subject:        Addition of CmdSN in Data-out PDU

Please can the CmdSN be added to the Data-out PDU to improve 
implementations
when receiving unsolicited Data-out PDUs:

Currently, implementations have to search the command queue list for the
associated command using the ITT as the search criteria.  For solicited
Data-out PDUs this is not an issue as they contain the Target Task Tag.
However, for unsolicated Data PDUs (Target Task Tag = 0xFFFFFFFF) the
locating of the associated command can be greatly enhanced by adding the
Associated CmdSN to Data-out PDU.

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

---

From: andy currid <[email-masked]>
Date: Tue, 9 Oct 2001 11:25:58 -0700 (PDT)

Julian, all

I second Matthew's request to have CmdSN present in DataOut PDUs.
I'm yet to be convinced of the value of unsolicited DataOut PDUs
in iSCSI, but if they're in the spec, they might as well be amenable
to efficient handling by targets.

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.).

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.

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. In an unsolicited data out, checking CmdSN
is likely cheaper than the current check we are forced to do with ITT.

Regards

Andy

> --

--
Andy Currid                                       [email-masked]
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

---

From: Paul Koning <[email-masked]>
Date: Tue, 9 Oct 2001 15:59:43 -0400

Excerpt of message (sent 9 October 2001) by andy currid:
> ...

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.
 
> the target is almost certainly a constant time operation.

Exactly.
 
> 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: Santosh Rao <[email-masked]>
Date: Tue, 09 Oct 2001 18:12:03 -0700

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

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: andy currid <[email-masked]>
Date: Tue, 9 Oct 2001 19:01:46 -0700 (PDT)

Santosh

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

Andy