SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Addition of CmdSN in Data-out PDU



    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





Home

Last updated: Wed Oct 10 13:17:22 2001
7181 messages in chronological order