Re: iSCSI: NOPs should not have a CmdSN

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

David,

Right!..there is still a synchronization problem 
to get hold of that immediate command slot at the session level.  

As regards this statement..
>    For immediate commands,
>    the CmdSN field can take any value from ExpCmdSN to MaxCmdSN+1.
>    The target MUST silently ignore any command outside this range

This was introduced to enable the initiator to send an immediate
command even when the queue is full (max+1 is allowed)
This was required for abort tasks.

One more thing to note in all this is (i believe) Abort Task
management PDUs now have a refCmdSN field (cmdSN of original task)

If we could explicitly state the requirements under which immediate
commands will be used, maybe we can solve this problem better
instead of imposing general constraints on how to deal with
the immediate commands, cmdSNs and flow control problems.

Are these the only possible cases ?
a) Ping commands - can we allow one immediate command per connection
   and ignore cmdSN field (and solve the problem David pointed out)
b) Abort Task commands - do not allocate a cmdSN to only allow one
   outstanding command OR allow a prenegotiated number (ugh..one
   more queue to manage!)

-Sandeep

Black_David@emc.com wrote:
> 
> > As for flow control, shouldn't we make the assumption that
> > immediate commands are executed synchronously (at sender
> > and receiver) and hence there can be only 1 outstanding
> > immediate command ?
> 
> I think this recreates Matt's problem because it requires
> contacting the session manager to get permission to send
> the only immediate command - Matt would need at least an
> immediate command per connection to avoid having to
> ask permission in this fashion.  I suspect this increases
> the importance of a flow control solution for immediate
> commands.
> 
> > Currently this is achieved by assigning
> > "maxCmdSN+1" but given the problem Matt pointed out, maybe we
> > should explicitly say cmdSN must be ignored when immediate flag
> > is set.
> 
> There's another reason why that might be a good thing
> to do.  In Section 1.2.2.1, near the bottom of
> page 12, the -06 draft says:
> 
>    For immediate commands,
>    the CmdSN field can take any value from ExpCmdSN to MaxCmdSN+1.
>    The target MUST silently ignore any command outside this range
> 
> 
> The CmdSN in an immediate command will be used by a
> non-immediate command, so suppose that CmdSN is 6.
> Receipt of non-immediate command whose CmdSN is 6
> (e.g., via a different connection) sets ExpCmdSN at
> the Target to a larger value, 7 in this example,
> causing the immediate command to be ignored because
> its CmdSN (6) is smaller than ExpCmdSN (7).  That
> doesn't strike me as the right result.  What is
> that "MUST silently ignore" protecting us from?


> 
> Comments?
> --David
> 
> > -----Original Message-----
> > From: Sandeep Joshi [SMTP:sandeepj@research.bell-labs.com]
> > Sent: Friday, July 13, 2001 6:33 PM
> > To:   Black_David@emc.com
> > Cc:   matt_wakeley@agilent.com; ips@ece.cmu.edu
> > Subject:      Re: iSCSI: NOPs should not have a CmdSN
> >
> >
> > This (cmdSN allocation) was *not* a problem in previous versions (e.g.
> > see NopOut PDU in draft 4), since CmdSN=0 was used to indicate
> > immediate delivery.
> >
> > With the introduction of the immediate flag, we now require an
> > explicit cmdSN to be allocated.
> >
> > As for flow control, shouldn't we make the assumption that
> > immediate commands are executed synchronously (at sender
> > and receiver) and hence there can be only 1 outstanding
> > immediate command ?   Currently this is achieved by assigning
> > "maxCmdSN+1" but given the problem Matt pointed out, maybe we
> > should explicitly say cmdSN must be ignored when immediate flag
> > is set.
> >
> > -Sandeep
> >
> > Black_David@emc.com wrote:
> > >
> > > What about flow control of commands arriving at the
> > > Target and associated Target resource management?
> > >
> > > This sounds like yet another use for "immediate"
> > > delivery, which I don't recall being
> > > resolved to everyone's satisfaction in prior
> > > discussion.
> > >
> > > --David
> > >
> > > > -----Original Message-----
> > > > From: Matt Wakeley [SMTP:matt_wakeley@agilent.com]
> > > > Sent: Friday, July 13, 2001 5:45 PM
> > > > To:   IPS Reflector
> > > > Subject:      iSCSI: NOPs should not have a CmdSN
> > > >
> > > > Normally on an active connection, when a command response is received,
> > the
> > > > initiator can acknowledge the response by setting ExpStatSN in the
> > next
> > > > command sent.
> > > >
> > > > However, on a relative inactive connection, it may be some time before
> > the
> > > > next command is sent.  But the initiator should acknowledge the
> > command
> > > > response in a timely fashion so the target can de-allocate the
> > "replay"
> > > > resources for the command.  The initiator does this by sending NOP.
> > > >
> > > > However, the NOP requires a CmdSN.  CmdSN is managed on a session wide
> > > > basis.
> > > > StatSN is managed on a connection basis.  In the case where there are
> > > > multiple
> > > > connections active in the session on different iSCSI NICs, the session
> > > > manager
> > > > that resides in the host manages the CmdSN.  Therefore, if the
> > connection
> > > > manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on
> > an
> > > > idle
> > > > connection, it must ask the session manager to do so, since it doesn't
> > > > have
> > > > visibility to the next CmdSN.
> > > >
> > > > To resolve this complexity, I propose removing CmdSN from the NOP.  I
> > see
> > > > no
> > > > reason why NOPs need to be processed "in order" across the session.
> > > >
> > > > -Matt Wakeley
> > > > Agilent Technologies