Re: iSCSI - Change Proposal X bit

["Mallikarjun C." <cbm@rose.hp.com>]

Sandeep,

>because we allow the maxCmdSN to increase
> unbounded in the presence of unacked statSNs.

That's true!  Two concerns -

- We have been using CmdSN at the target only
  for reordering of commands, and it becomes irrelevant
  once a SCSI task is instantiated (section 2.2.2.1).  
  Your suggestion doesn't appear to conform to this 
  idea - in fact it seems to require CmdSN association
  beyond the task conclusion.

- CmdSN credit management is an iSCSI session activity,
  and tying session level credit management with StatSN
  ACKs that happen at a connection level doesn't seem to
  enable a clean "session manager" separation spanning 
  multiple NICs.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


Sandeep Joshi wrote:
> 
> Mallikarjun,
> 
> This problem can be solved _without_ introducing
> any additional I/O activity.   Notice that it
> occurs because we allow the maxCmdSN to increase
> unbounded in the presence of unacked statSNs.
> 
> The target can prevent this from happening.
> 
> Imagine some connection A at the target :
> 
> (1) Everytime the target sends a new statSN out, it
>     records the cmdSN for that statSN
>     (say Connection_A.cmdSN_of_last_statSN = 200)
> 
> (2) While growing maxCmdSN at target, ensure that
>     (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1)
> 
>     This is stricter than current condition
>     (maxCmdSN - expCmdSN) < 2^31-1
> 
>     If there are N connections, use least value of
>     cmdSN_of_last_statSN.
> 
> (3) All retried commands will always fall outside
>         the window.  They will be on the "dark side".
> 
> (4) If the target cant grow maxCmdSN, it closes the
>     offending connection, or sends out NOPs.
> 
> Works ..?
> 
> -Sandeep
> 
> > In helping others walk through your scenario here in HP,
> > we all realized that the core solution to the problem
> > is to mandate a complete execution of a numbered command
> > (some I/O activity that is trackable) on each connection
> > once at least every (2^32 -1) commands.  It may be a NOP,
> > or any regular command.  So, here is my suggestion -
> >
> >   An initiator MUST send at least one non-immediate command
> >   on each of the connections participating in the session,
> >   for every (2^31 -1) numbered commands.
> >
> > Comments?
> > --
> > Mallikarjun