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



    
    Eddy,
    
    I was referring to Sec 2.2.5
    
       Unsolicited data MUST be sent on every connection in the 
       same order in which commands were sent
    
    -Sandeep
    
    Eddy Quicksall wrote:
    > 
    > 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 14:17:24 2001
7198 messages in chronological order