Subject: Re: iSCSI: NOPs should not have a CmdSN

From: "Matt Wakeley" <[email-masked]>
Date: Fri, 13 Jul 2001 15:12:51 -0700

[email-masked] 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.

You're right about the flow control.  The immediate commands have the same
flow control problem, because in their case, the CmdSN is not advanced.  From
1.2.2.1:

"Commands meant for immediate delivery are marked as such through an
immediate delivery flag. They carry the same CmdSN as that which
would have been given to a non-immediate command but the CmdSN is not
advanced for immediate commands."

-Matt

---

From: [email-masked]
Date: Fri, 13 Jul 2001 17:54:19 -0400

--David

> -----Original Message-----
> From:	Matt Wakeley [SMTP:[email-masked]]
> 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

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 13 Jul 2001 18:33:00 -0400

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