Re: Addition of CmdSN in Data-out PDU

[Santosh Rao <santoshr@cup.hp.com>]

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


Paul Koning wrote:
> 
> 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

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################