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



    You can't assume the ITT takes a specific order.
    
    Eddy
    
    -----Original Message-----
    From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
    Sent: Thursday, October 11, 2001 10:30 AM
    To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
    Cc: 'Paul Koning'; ips@ece.cmu.edu
    Subject: Re: Addition of CmdSN in Data-out PDU
    
    
    
    
    If we use the fact that the ITT-ordering of the unsolicited
    Data-out PDUs is identical to the ITT-ordering of the commands
    sent *within* a connection, then it should be possible to 
    resolve the Data-out PDUs in a constant-time operation[*1]
    No hash and no cmdSN is required keep a per-connection
    chain within the command queue and look at its head.
    
    [*1]There are a couple of exceptions, due to the leeway the
        standard provides the initiator on Data-out PDUs.
    
    -Sandeep
    
    "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
    > 
    > Since I started this thread I feel I must at least contribute!
    > 
    > The reason why I proposed putting CmdSN (actually it should be
    RefCmdSN) in
    > the Data-out PDUs was to enable the target to have a faster search to
    > associate unsolicited data out PDUs with its SCSI Command PDU.
    Solicited
    > Data-out PDUs do not require this as they have a Target Task Tag.
    > 
    > If all Command PDUs were queued then I believe this would work just
    fine.
    > However, as Santosh correctly pointed out they are not and without
    repeating
    > what he said this mechanism would not work for immediate command PDUs.
    > 
    > I am sure that particular implementations could make this work but the
    > underlying argument is that it needs to work and be useful to all
    > implementations.  The only benefit I now see of having CmdSN in the
    data PDU
    > is as a check as implementations must (and can only) use the initiator
    task
    > tag to associated the Data-out PDU with the command PDU.  Therefore,
    IMO it
    > is not a good enough reason for having CmdSN in the Data-out PDUs
    simply for
    > a consistency check.
    > 
    > The benefit of having the data sent unsolicited to minimise if not
    eradicate
    > round trip times far out weighs the overhead in having to perform a
    search
    > on receipt of unsolicited data. If we could have developed a well
    defined
    > mechanism to overcome this overhead then all well and good and that is
    what
    > I attempted.  Still, if someone can do this and the solution is simple
    and
    > straight forward then I am sure that it will have my backing but until
    then
    > ...
    > 
    > Cheers
    > 
    > Matthew Burbridge
    > Senior Development Engineer
    > NIS-Bristol
    > Hewlett Packard
    > Telnet: 312 7010
    > E-mail: matthewb@bri.hp.com
    > 
    > 
    > -----Original Message-----
    > From: Paul Koning [mailto:pkoning@jlc.net]
    > Sent: Wednesday, October 10, 2001 5:07 PM
    > To: Julian_Satran@il.ibm.com
    > Cc: ips@ece.cmu.edu
    > Subject: Re: Addition of CmdSN in Data-out PDU
    > 
    > Excerpt of message (sent 10 October 2001) by Julian Satran:
    > > 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.
    > 
    > 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
    


Home

Last updated: Thu Oct 11 13:17:25 2001
7197 messages in chronological order