RE: [iSCSI] Resolution of management commands and multiple head of queue commands.

["Douglas Otis" <dotis@sanlight.net>]

As a follow on:

iSCSI .7

RE: Immediate Delivery

        "Please note that the number of commands used for immediate delivery
        is not limited and their delivery to execution is not acknowledged
        through the numbering scheme.  Immediate commands can be rejected by
        the iSCSI target due to lack of resources. An iSCSI target MUST be
        able to handle at least one immediate task management command and
one
        immediate non-task-management iSCSI request per connection at any
        time."

RE: Reject

        "It may happen that a target receives a PDU with a format error
(e.g.,
        inconsistent fields etc.) or a digest error (e.g., invalid payload
or
        header). The target returns the header (not including digest) of the
        PDU in error as the data of the response."

Unlike any other command, Immediate Delivery Commands are not regulated by
the Target.  It is clear however that even to reject these commands, there
needs to be resources.  If there is resouces, then there is not a problem,
if there is not resouces, then the logic seems broken.

Doug

> Immediate commands don't just get discarded - they are rejected.
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 06-08-2001 16:57:42
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "Ips" <ips@ece.cmu.edu>
> cc:
> Subject:  [iSCSI] Resolution of management commands and multiple head of
>       queue commands.
>
>
>
> All,
>
> iSCSI version .7 is a significant improvement.  Two areas that prompted a
> draft still seem unresolved.  Section 8.1 mentions a potential problem
> without addressing at least a suggested means of handling these
> situations.
> There are management commands that can not resolve with connection
> allegiance alone.  On another point, with no assurance or direct
> confirmation of Immediate Delivery Commands (IDC) and the potential for
> only
> a single command resource being allocated by the target, one must wonder
> how
> these commands are to be handled in practice.  Preventing more than a
> single
> command to be sent as IDC would be one solution as there is
> assurance there
> will be resources for only a single command.  If this were to be
> adopted as
> the method of handling these IDC commands, then such a flag could serve to
> allow an exception to the command window limit and avoid creating an
> overlaid command sequence count that then only serves to befuddle
> acknowledgement.  If multiple IDC commands need to be sent, then either
> waiting for acknowledgement or sending these commands consecutively where
> acknowledgement would indicate quickly status of these commands
> without the
> initiator pondering their status at a point in time where speed of
> resolution is important.
>
> Doug
>
>
>
>
>