RE: iSCSI: NOPs should not have a CmdSN

[Black_David@emc.com]

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