Re: Addition of CmdSN in Data-out PDU

[andy currid <andy@windriver.com>]

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


> 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)" <matthew_burbridge@hp.com>
> 08-10-01 12:30
> Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
> 
>  
>         To:     ips@ece.cmu.edu, 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: matthewb@bri.hp.com


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