RE: iSCSI: NOPs should not have a CmdSN

["Dev - Platys" <deva@platys.com>]

>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.

I agree with this proposal.

Deva
Platys Communications


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Matt Wakeley
Sent: Friday, July 13, 2001 2: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