RE: Addition of CmdSN in Data-out PDU

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

Sandeep,

You are right. The target has knowledge of whether
a Data-out PDU will be received, and also the order in
which they will be received. This allows the target
to determine the command with which the data is
associated without having to search by the ITT.
A mismatch would indicate a missing pdu due to
digest error, or a protocol violation.

Somesh

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Sandeep Joshi
> Sent: Thursday, October 11, 2001 9:21 AM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu
> Subject: 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
>