Subject: iSCSI: ordered command delivery at the target

From: Luben Tuikov <[email-masked]>
Date: Fri, 07 Jun 2002 12:06:53 -0400

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

---

From: "Amir Shalit" <[email-masked]>
Date: Fri, 7 Jun 2002 09:44:14 -0700

It does it for new commands but not for existing once
like what you are suggesting. It's all about "delivery".

Amir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Luben Tuikov
Sent: Friday, June 07, 2002 9:40 AM
To: Amir Shalit
Cc: iSCSI; Julian Satran
Subject: Re: iSCSI: ordered command delivery at the target

Amir Shalit wrote:
>
> 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

The target takes care or CmdSN wrapping for outstanding ITT,
by virtue of MaxCmdSN and ExpCmdSN.
If it didn't, all would go up in smoke! Please read the draft!
Anyway...

Comments? (on the original posting).

--
Luben

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 07 Jun 2002 12:40:25 -0400

Amir Shalit wrote:
> 
> It will not work. If you issue a write command for multiple Terabytes (it's
> allowed)

-- 
Luben

---

From: "Amir Shalit" <[email-masked]>
Date: Fri, 7 Jun 2002 09:30:05 -0700

Amir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]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

Comments?

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 07 Jun 2002 12:56:45 -0400

> like what you are suggesting. It's all about "delivery".

Even the more reason to implement this.

Once a command has been delivered for execution to the
device server, this means that Data-out pdu's (if any)
have already been delivered (i.e. the command with its
data (if any) has been delivered to the target).
Thus no new ones are coming, thus, CmdSN may wrap
around that CmdSN (submitted task).

As for SNACK -- it will become a command
if assigned CmdSN. (i.e. no reference to tasks,
since they are refered to by SNACK->ITT).
And for SNACK of type DataAck, this can be
Immediate since the Target is keeping the whole
thing into a ``pending (data) ack'' queue.

Anyway...

Comments? (on the original postng)

-- 
Luben

---

From: Paul Koning <[email-masked]>
Date: Fri, 7 Jun 2002 13:44:03 -0400

>>>>> "Luben" == Luben Tuikov <[email-masked]> writes:

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

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

Let's defer all further packet format changes to iSCSI V2.  

      paul