|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Addition of CmdSN in Data-out PDUCan 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 > > > > > > >
Home Last updated: Sat Oct 20 23:17:30 2001 7309 messages in chronological order |