|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: NOP-Out closing the command windowSandeep, They are 3 distinguishing elements P and the ITT+TTT. Julo Sandeep Joshi <sandeepj@research.bell-labs.com> on 27-07-2001 18:53:20 Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com> To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: NOP-Out closing the command window If the NOP-Out does not have the ping-bit set, then it is a ping response and *not* a new command being issued by the initiator. Hence, it seems that the NOP-OUT with P=0 need not carry a new cmdSN (Mark's 2nd option). Btw, I did not know the 2nd sequence (P=0 from initiator?) below was valid > I->T NOP +P=0 +I=x+ Data > T->I NOP +P=0 +I=x -Sandeep Julian Satran wrote: > > Mark, > > Definitely a problem . How about stating (the obvious) that NOP as any > thing carying an ITT expectes an answer > wheter it carries an echo (P=1) or not (P=0). > > If it does not carry an ITT it does not. > > We can have the following sequences all valid: > > I->T NOP +P=1 +I=x+ Data > T->I NOP +P=0 + Data > > I->T NOP +P=0 +I=x+ Data > T->I NOP +P=0 +I=x > > T->I NOP +P=1 +TTT > I->T NOP +P=0 I=1 + TTT (no ITT) > > All would be permitted today if we remove the tie between ITT and P say > that NOP must have an ITT if issued at initiators initiative. > > We might add as valid (today it is not, it is explicitly forbidden): > > T->I NOP +P=1 +TTT > I->T NOP +P=1+ I= 1 TTT + ITT + Data > T->I NOP +P=0 +ITT + Data > > The last requires us to "tweak" the termination rule (a target is forbiden > to answer a P=1 with a P=1 > > comments? > Julo > > Mark Bakke <mbakke@cisco.com> on 27-07-2001 16:25:20 > > Please respond to Mark Bakke <mbakke@cisco.com> > > To: IPS <ips@ece.cmu.edu> > cc: > Subject: iSCSI: NOP-Out closing the command window > > When sending a NOP-Out without the P bit set, there's > no response to update ExpCmdSN to keep the window open. > > On an otherwise idle session, sending a long enough > sequence of these NOP-Outs can close the command window > permanently. > > In case of a stuck command window, please break glass... > > The easy solution is to turn on the P bit, and get the > responses to update the window, but that defaults the > purpose of allowing the P bit to not be set in the first > place. > > Another easy solution (but I almost hate to mention it) > is not to have NOP-Out update the CmdSN. This seems to > have the possibility of breaking other things. > > I suppose we could come up with a more complicated rule, > like "if the NOP-Out's CmdSN would be the last (or perhaps > penultimate) CmdSN allowed by the current window, it MUST > set the P bit." Or something like that. > > Anyway, I see three possible solutions. Any thoughts? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054
Home Last updated: Tue Sep 04 01:04:11 2001 6315 messages in chronological order |