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

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

Sandeep,

About the mechanical setup - I was perhaps unclear but the issue is that
getting the commands earlier helps.

If you send c1,c2,c3... data 1, data2 ...

c2 will get its command and start its mechanical setup earlier than in:

c1 data1, c2 data2...

I was not conerned about buffers but about letting command through as early
as possible when it makes sense.
My design rule of thumb was "don't impose scheduling restrictions if you
don't have to".

The TAGs for NOP-IN was mainly to enable tags to be generated independently
in independent units.
My assumption was that together with the LUNs they will give targets enough
room for "uniqueness".

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 27-08-2001
22:47:51

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i




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