Re: iSCSI: draft 7: remove S bit and Status field from the Data-i

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Julian,

Wouldn't mechanical setup could go in parallel with network data 
reception anyways?  A target which has advertised a certain command 
window must also have reserved memory for the corresponding 
unsolicited bursts.  

So I guess I am still unconvinced..but can workaround if there 
aren't other supporters for the new ordering.

Btw, this "mechanical setup" rationale as well as the LUN tags in 
NOP-in (stated purpose: can be used to route NOP-ins to LUNs) 
seem to assume some model of an iSCSI storage target (JBOD/RAID), 
which is  perhaps external to what's in SAM-2.  
Just guessing, not sure. If there is some model, do share it with 
us since it may help see the design rationales.

Regards,
-Sandeep

Julian Satran wrote:
> 
> Sandeep,
> 
> It is not difficult but can be counterproductive.
> Lets assume that you have in the pipe 7 commands for 7 LUs (that can
> effectively execute in parallel) and all of them require
> some mechanical setup before they can effectively handle data.
> The rules in force today will allow the initiator to send out the commands
> (and let the mechanical setup start) and send the data afterwards (in the
> same order the commands where set).
> 
> The alternative will force order (without necessarily buying us anything)
> and disable the above optimization.
> 
> In the spec we set rules so that deadlocks will not occur (keep the same
> order as commands) but left room for optimization.
> 
> Julo
> 
> Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
> 27-08-2001 18:07:10
> 
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> 
> Sent by:  sandeepj@research.bell-labs.com
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
> 
> Julian,
> 
> I am probably missing something here..especially
> now that you refer to multiplexing.
> 
> The rule would be per-connection - why it is difficult
> for the initiator to send the unsolicited data _right_
> after the command ?  The data is already available from
> the ULP.
> 
> If this new rule is not added, the target needs
> to route unsolicited PDUs based on ITT (..a foreign tag)
> Its not a checking burden but a performance gain.
> 
> The only other cases which requires ITT routing at the
> target are abort-task, D-SNACK and command-retry, all
> of which we can assume to be infrequent and not in the
> performance path.
> 
> -Sandeep
> 
> P.S. Let me throw in some casuistry...this is also why
> dog owners are made to follow dogs, so one doesnt need
> to look at dog tags :-)
> 
> Julian Satran wrote:
> >
> > I am sure we don't want to enter this. The sequencing rules are there to
> > asure:
> >
> >    that there is no deadlock (order of data must follow the order of
> >    commands)
> >    that the target command buffer does not overflow (MaxCmdSN) - this
> will
> >    eliminate an "unlimited number of immediate"
> >
> > Any additional rules will interfere with performance, multiplexing policy
> > etc. and I see no great
> > value in enforcing them (and enforcing means checking and that means
> > expense).
> >
> > Julo
> >
> > Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 26-08-2001
> > 00:11:39
> >
> > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   Dave Sheehy <dbs@acropora.rose.agilent.com>
> > cc:   IETF IP SAN Reflector <ips@ece.cmu.edu>
> > Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the
> Data-i
> >
> > Julian,
> >
> > I wonder if Dave's last paragraph in this email has been considered.
> > Here it is again..
> >
> > > This does help some. It eliminates the situation where a target can
> > receive
> > > an essentially unlimited number of immediate data commands prior to
> > receiving
> > > *any* data PDUs.
> >
> > in reference to Section 1.2.5
> > > Unsolicited data MUST be sent on
> > > every connection in the same order in which commands were sent.
> >
> > The draft currently allows
> >    c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
> > where c-N = command {N}
> > and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
> > {N}
> >
> > It would be simplify target login (ITT lookup) if we only permitted
> > this sequence.
> >    c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..
> >
> > -Sandeep
> >
> > Dave Sheehy wrote:
> > >
> > > David,
> > >
> > > > I think you've taken a wrong turn.
> > >
> > > I think John hit the nail on the head.
> > >
> > > > > Second, thoughts of removing the immediate data seem not to be
> > > > > simplification, since all the information to tie the data to the
> > command
> > > > is
> > > > > right there with the command.  That has got to be easier than
> > matching up
> > > > > separate PDUs of data with the appropriate commands.
> > > >
> > > > Actually, that was the point, since the logic for "matching up
> separate
> > > > PDUs of data with the appropriate commands" has to exist for inbound
> > > > Data PDUs already.
> > >
> > > Except that there is a target context present in the solicited case to
> > route
> > > the data. That doesn't exist in the unsolicited case.
> > >
> > > > The slide I presented in London was about replacing
> > > > immediate data with an unsolicited data PDU immediately following the
> > > > command, thus removing the immediate data case in favor of reusing
> the
> > > > logic for dealing with separate Data PDUs.  Remember that this was
> > presented
> > > > as a simplification possibility.
> > >
> > > This does help some. It eliminates the situation where a target can
> > receive
> > > an essentially unlimited number of immediate data commands prior to
> > receiving
> > > *any* data PDUs.
> > >
> > > But, do you mean to say that *one* unsolicited data PDU would follow
> the
> > > command? Wouldn't that be unnecessarily restrictive if the PDU size is
> > small?
> > > Simply guaranteeing that the data PDUs will immediately follow the
> > command
> > > seems like an adequate improvement.
> > >
> > > Dave Sheehy