RE: Addition of CmdSN in Data-out PDU

["Julian Satran" <Julian_Satran@il.ibm.com>]

Robert,

Closing the window is a common event on TCP connection.
The deadlock can occur only if a command sends its data while the target 
requests data for an earlier command.

Julo




Robert Snively <rsnively@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu
15-10-01 22:59
Please respond to Robert Snively

 
        To:     Julian Satran/Haifa/IBM@IBMIL, John Hufferd/San Jose/IBM@IBMUS
        cc:     "'Binford, Charles'" <CBinford@pirus.com>, ips@ece.cmu.edu, 
"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>, 
owner-ips@ece.cmu.edu, Robert Snively <rsnively@Brocade.COM>, 
"'somesh_gupta@silverbacksystems.com'" 
<somesh_gupta@silverbacksystems.com>
        Subject:        RE: Addition of CmdSN in Data-out PDU

 

Can they send enough commands to close the window just
as fatally?


> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, October 13, 2001 1:09 PM
> To: John Hufferd
> Cc: 'Binford, Charles'; ips@ece.cmu.edu; BURBRIDGE,MATTHEW
> (HP-UnitedKingdom,ex2); owner-ips@ece.cmu.edu; Robert Snively;
> 'somesh_gupta@silverbacksystems.com'
> Subject: RE: Addition of CmdSN in Data-out PDU
> 
> 
> Robert,
> 
> The reason for the rule is limiting restrictions to what is logically 
> mandated and leaving all the rest to the implementer.
> The ordering rule is there to help avoid the trivial deadlock where 
> commands start asking for solicited data and the windows is closed by 
> unsolicited data  and having to resort to dropping data to 
> reopen the TCP 
> window.
> 
> Having data immediately follow the command is admisible but some 
> implementer might choose to have and launch as many commands 
> as possible 
> to get the data transfer overlap with positioning operations.
> 
> The targets are supposed to consider out of order delivery of data a 
> protocol error.
> 
> Regards,
> Julo
> 
> 
> 
> 
> John Hufferd/San Jose/IBM@IBMUS
> Sent by: owner-ips@ece.cmu.edu
> 13-10-01 02:01
> Please respond to John Hufferd
> 
> 
>         To:     Robert Snively <rsnively@Brocade.COM>
>         cc:     "'somesh_gupta@silverbacksystems.com'" 
> <somesh_gupta@silverbacksystems.com>, "BURBRIDGE,MATTHEW 
> (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>, 
> "'Binford, Charles'" 
> <CBinford@pirus.com>, ips@ece.cmu.edu
>         Subject:        RE: Addition of CmdSN in Data-out PDU
> 
> 
> 
> 
> Robert,
> I think that an Initiator being able to send a waiting Read command,
> without having to wait for many large write segments -- that 
> are being 
> sent
> (as unsolicited data) -- is very useful.  And that would mean, the
> unsolicited data is waiting to be sent until the Read 
> Commands are sent.
> This might be a very frequent case.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
> 
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 
> 10/12/2001 03:56:06 
> PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'somesh_gupta@silverbacksystems.com'"
>       <somesh_gupta@silverbacksystems.com>, "BURBRIDGE,MATTHEW
>       (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>, "'Binford,
>       Charles'" <CBinford@pirus.com>, ips@ece.cmu.edu
> cc:
> Subject:  RE: Addition of CmdSN in Data-out PDU
> 
> 
> 
> I have two small questions that would help me understand this.
> 
> How do you know that unsolicited data is expected?  By nature,
> unsolicited data is received as a "maximum surprise" which can
> only be determined after unpacking and parsing at least a
> part of the command structure, possibly even including the
> SCSI command (although there are some hints contained in the
> command header information).
> 
> How can you constrain a generic system to posting the
> unsolicited data in the same order that the commands were
> emitted?  In general, I would have expected the system to
> be emitting command followed immediately by the corresponding
> unsolicited data.  If that is not the case, it means that there
> was a delay in obtaining the unsolicited data for transfer and
> that the delay was sufficient to allow the insertion of commands.
> If the delay is that large (and probably variable), the enforcement
> of transfer of unsolicited data in the same order as the
> commands are emitted seems to me to be a significant challenge,
> and certainly shouldn't be required as normal behavior.  While it
> would make things simpler for targets (already challenged by
> unsolicited data), it seems to me that it would make things
> much more complex for initiators.
> 
> Bob
> 
> > -----Original Message-----
> > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com]
> > Sent: Friday, October 12, 2001 2:51 PM
> > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles';
> > ips@ece.cmu.edu
> > Subject: RE: Addition of CmdSN in Data-out PDU
> >
> >
> > Matthew,
> >
> > Since the unsolicited data does not follow the
> > command, you need the link list. But since the
> > unsolicited data must be sent in the same order
> > as the commands, a link list is enough.
> >
> > Let us say that you have 8 commands. The ones
> > for which we expect unsolicted data are marked
> > as Cnn(ud). And I have marked the unsolicted
> > data PDUs as UD(nn). The (nn) with data implies
> > that it is implicit and not actually carried with
> > the PDU itself.
> >
> > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) --->
> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) --->
> > --> UD(07) C08(ud) UD(08) --->
> >
> > After the target receives the command C01, C02, and C03
> > for which it expects unsolicited data, it puts them in
> > a link list. It also receives C04 and C05 for which
> > unsolicited data is not expected and they don't go
> > on the list. It then receives C06 for which unsolicited
> > data is expected, and it is added to then end of the list.
> > Then an unsolicited data PDU is received. It must go
> > with the command at the head of the list which is C01.
> > Use the ITT to make sure and you can then take C01 off
> > the list and so on.
> >
> > Somesh
> >
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu
> > [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> > > Sent: Friday, October 12, 2001 7:53 AM
> > > To: 'Binford, Charles'; ips@ece.cmu.edu
> > > Subject: RE: Addition of CmdSN in Data-out PDU
> > >
> > >
> > > Charles,
> > >
> > > As you have described the spec states that "that
> > unsolicited data MUST be
> > > sent in the same order as the commands".  This is not the same as
> > > unsolicited data must follow the command associated with
> > it:  For example:
> > >
> > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The
> > x in all the
> > > example can be the ITT. It is not the CmdSN.
> > >
> > > This is allowed:
> > >
> > >   C1 C2 C3 D1 D2 C4 D3 D4
> > >
> > > and the target will have to use the ITT to associate the
> > data with the
> > > command.
> > >
> > > Matthew
> > >
> > >
> > > -----Original Message-----
> > > From: Binford, Charles [mailto:CBinford@pirus.com]
> > > Sent: Friday, October 12, 2001 2:50 PM
> > > To: ips@ece.cmu.edu
> > > Subject: RE: Addition of CmdSN in Data-out PDU
> > >
> > >
> > > I have not verify version 8 is still the same, but version 07-97
> > > had a rule
> > > that unsolicited data MUST be sent in the same order as the
> > commands.
> > >
> > > Thus, there is no need for a search on the ITT.  The target
> > just needs to
> > > keep of linked list of I/Os waiting on unsolicited data.
> > New commands are
> > > added to the tail, any unsolicited data *should* be associated
> > > with the I/O
> > > at the head of the list.  The ITT is used as a sanity check and
> > > you're done.
> > >
> > > What am I missing?
> > >
> > > Charles Binford
> > > Pirus Networks
> > > 316.315.0382 x222
> 
> 
> 
> 
> 
> 
>