RE: iSCSI: ordered command delivery at the target

["Amir Shalit" <amir@astutenetworks.com>]

It will not work. If you issue a write command for multiple Terabytes (it's
allowed)
CmdSN may wrap before you are done with the command.

Amir

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Luben Tuikov
Sent: Friday, June 07, 2002 9:07 AM
To: iSCSI; Julian Satran
Subject: iSCSI: ordered command delivery at the target


To achieve ordered command  delivery (2.2.2.1),
the Target will most likely put the requests
it gets from the Initiator into an ``incoming''
priority queue by CmdSn, after connection allegiance
has been noted. The priority queue is at session level,
by reason of iSCSI/SCSI and CmdSN.

Currently offset 24 is used for CmdSN (Requests) and
for StatSN (Responses) which is a good thing (since they
are exclusive).

>From all the Requests, only Data-Out and SNACK,
reserve offset 24, which would break insertion
into the ``incoming'' priority queue.

Since SCSI Command (Request) is assigned CmdSN
as well as ITT, why not stupulate that Data-Out
has to carry the same CmdSN as the task to which
they belong (by ITT).

This would alleviate the target from searching all
of its queues for the ITT in order to extract the CmdSN,
and then put the Data-Out PDU into the ``incoming''
priority queue by the found CmdSN.

This _simplifies_ the Target, and makes no load on the
initiator since the initiator can just copy the CmdSN
on subsequent Data-Out.

Effectively, this just helps insertion into the
Target's ``incoming'' priority queue.

Also, I see no reason not to make SNACK a command
and assign it a CmdSN. If the Initiator is certain
that the command it is referencing has completed
(e.g. StatusACK)
then SNACK can be an immediate command (I = 1), thus
it will be put at the front of the ``incoming''
priority queue (effectively ignoring CmdSN),
and delivered for execution right away.
The Target implementation will then only search
execution/outgoing queues by ITT (StatusACK) and be able to find
the task by ITT. (1)

Otherwise, CmdSN will just put it right after the
ITT which bears the same CmdSN, iff ITT hasn't been
sent for execution. Then the ITT is posted for execution
and the Target will have to search only the
execution/outgoing queues just as mentioned in (1) above.

Yes, I know that CmdSN has no meaning after the command
has been passed to the device server at the Target.
Thus the more reason to make the Initiator copy CmdSN
for Data-Out and SNACK***.

*** So, if the task has been delivered for executon
at the Target, then the Data-Out will _naturally_
be put at the FRONT of the ``incoming'' priority queue
(since the task is in another queue and CmdSN has advanced),
thus effectively making it immediate, which is the desired effect.
If the task has NOT been posted for execution at the
target, the Data-Out will be queued right after it.

Comments?

--
Luben
P.S. Anyone implementing iSCSI Connection load balancing
at the initiator would've certainly considered this since
it would also make the target execution engine simpler.
(They go hand-in-hand.)