Re: iSCSI: NOPs should not have a CmdSN

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

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