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

From: [email-masked]
Date: Wed, 15 Aug 2001 20:15:31 -0400

> > 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 is right - "an unsolicited data PDU" should have been "one or more
unsolicited data PDUs" - I was making the incorrect assumption that
immediate
data is always short (not necessarily the case, but perhaps common).

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Sandeep Joshi <[email-masked]>
Date: Mon, 27 Aug 2001 15:47:51 -0400

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 <[email-masked]>@research.bell-labs.com on
> 27-08-2001 18:07:10
> 
> Please respond to Sandeep Joshi <[email-masked]>
> 
> Sent by:  [email-masked]
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> 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 <[email-masked]>@ece.cmu.edu on 26-08-2001
> > 00:11:39
> >
> > Please respond to Sandeep Joshi <[email-masked]>
> >
> > Sent by:  [email-masked]
> >
> > To:   Dave Sheehy <[email-masked]>
> > cc:   IETF IP SAN Reflector <[email-masked]>
> > 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..
> >
> > 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.
> > >
> > > Dave Sheehy

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 28 Aug 2001 10:48:25 +0300

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 <[email-masked]>@ece.cmu.edu on 27-08-2001
22:47:51

To:   [email-masked]
cc:

Julian,

Regards,
-Sandeep

Data-i