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

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

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