Subject: RE: Addition of CmdSN in Data-out PDU

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Thu, 11 Oct 2001 09:21:29 +0100

Since I started this thread I feel I must at least contribute!

The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in
the Data-out PDUs was to enable the target to have a faster search to
associate unsolicited data out PDUs with its SCSI Command PDU.  Solicited
Data-out PDUs do not require this as they have a Target Task Tag.

If all Command PDUs were queued then I believe this would work just fine.
However, as Santosh correctly pointed out they are not and without repeating
what he said this mechanism would not work for immediate command PDUs.

I am sure that particular implementations could make this work but the
underlying argument is that it needs to work and be useful to all
implementations.  The only benefit I now see of having CmdSN in the data PDU
is as a check as implementations must (and can only) use the initiator task
tag to associated the Data-out PDU with the command PDU.  Therefore, IMO it
is not a good enough reason for having CmdSN in the Data-out PDUs simply for
a consistency check.

The benefit of having the data sent unsolicited to minimise if not eradicate
round trip times far out weighs the overhead in having to perform a search
on receipt of unsolicited data. If we could have developed a well defined
mechanism to overcome this overhead then all well and good and that is what
I attempted.  Still, if someone can do this and the solution is simple and
straight forward then I am sure that it will have my backing but until then
...

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 5:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Addition of CmdSN in Data-out PDU

Excerpt of message (sent 10 October 2001) by Julian Satran:
> Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it 
> may have large holes and using it in an implementation is as bad as a 
> hashed index.

Not true.

CmdSN values are sequential, by definition.  Yes, clearly there will
be small holes because commands complete out of order.  But "large"
holes are unlikely.

In any case, the target has control over that.  I can use an array
whose size is given by the number of pending commands times a
correction factor to account for the likely density of holes.  Then
MaxCmdSN would be updated based on two considerations: the ability to
handle more pending commands, and the need to keep the distance
between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the
size of the lookup array.

So having CmdSN in the DataOut PDU allows this approach, thereby
replacing a hash lookup on a rapidly changing ID space by a simple
array indexing operation.  Without CmdSN, you're forced to use a
mechanism that has a lot more overhead (in the insert/remove or in the
lookup, depending on the mechanism chosen).

	paul

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 11 Oct 2001 10:29:36 -0400

If we use the fact that the ITT-ordering of the unsolicited
Data-out PDUs is identical to the ITT-ordering of the commands
sent *within* a connection, then it should be possible to 
resolve the Data-out PDUs in a constant-time operation[*1]
No hash and no cmdSN is required keep a per-connection
chain within the command queue and look at its head.

[*1]There are a couple of exceptions, due to the leeway the
    standard provides the initiator on Data-out PDUs.

-Sandeep

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 11 Oct 2001 11:06:29 -0400

To support this, wouldn't we have to limit the number of outstanding
commands? This is because commands are passed to the SCSI layer as soon as
the CmdSN's are in order. But, the unsolicited data may still be due.

As soon as a command is passed to the SCSI layer, the ExpCmdSN is
incremented and the MaxCmdSN is computed to make best use of the buckets.
There would be a limited number of buckets.

If you use MaxCmdSN for this purpose, you would severely limit the number of
outstanding commands (to the size of your iSCSI command buckets).

Eddy

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:[email-masked]]
Sent: Thursday, October 11, 2001 04:21 AM
To: 'Paul Koning'
Cc: [email-masked]
Subject: RE: Addition of CmdSN in Data-out PDU

The reason why I proposed putting CmdSN (actually it should be RefCmdSN)
in
the Data-out PDUs was to enable the target to have a faster search to
associate unsolicited data out PDUs with its SCSI Command PDU.
Solicited
Data-out PDUs do not require this as they have a Target Task Tag.

If all Command PDUs were queued then I believe this would work just
fine.
However, as Santosh correctly pointed out they are not and without
repeating
what he said this mechanism would not work for immediate command PDUs.

I am sure that particular implementations could make this work but the
underlying argument is that it needs to work and be useful to all
implementations.  The only benefit I now see of having CmdSN in the data
PDU
is as a check as implementations must (and can only) use the initiator
task
tag to associated the Data-out PDU with the command PDU.  Therefore, IMO
it
is not a good enough reason for having CmdSN in the Data-out PDUs simply
for
a consistency check.

The benefit of having the data sent unsolicited to minimise if not
eradicate
round trip times far out weighs the overhead in having to perform a
search
on receipt of unsolicited data. If we could have developed a well
defined
mechanism to overcome this overhead then all well and good and that is
what
I attempted.  Still, if someone can do this and the solution is simple
and
straight forward then I am sure that it will have my backing but until
then
...

Cheers

Matthew Burbridge

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 5:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Addition of CmdSN in Data-out PDU

Not true.

	paul

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 11 Oct 2001 12:12:38 -0400

You can't assume the ITT takes a specific order.

Eddy

-----Original Message-----
From: Sandeep Joshi [mailto:[email-masked]]
Sent: Thursday, October 11, 2001 10:30 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Cc: 'Paul Koning'; [email-masked]
Subject: Re: Addition of CmdSN in Data-out PDU

-Sandeep

Solicited
fine.
repeating
task
eradicate
search
defined
what
and
then

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 11 Oct 2001 12:21:18 -0400

Eddy,

I was referring to Sec 2.2.5

   Unsolicited data MUST be sent on every connection in the 
   same order in which commands were sent

-Sandeep

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 11 Oct 2001 12:58:19 -0400

Thanks,

Now I see your point.

Eddy

-----Original Message-----
From: Sandeep Joshi [mailto:[email-masked]]
Sent: Thursday, October 11, 2001 12:21 PM
To: Eddy Quicksall
Cc: [email-masked]
Subject: Re: Addition of CmdSN in Data-out PDU

Eddy,

-Sandeep

Eddy Quicksall wrote:
> > > may have large holes and using it in an implementation is as bad
as
> a

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 11 Oct 2001 10:52:16 -0700

Sandeep,

You are right. The target has knowledge of whether
a Data-out PDU will be received, and also the order in
which they will be received. This allows the target
to determine the command with which the data is
associated without having to search by the ITT.
A mismatch would indicate a missing pdu due to
digest error, or a protocol violation.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sandeep Joshi
> Sent: Thursday, October 11, 2001 9:21 AM
> To: Eddy Quicksall
> Cc: [email-masked]