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

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Fri, 12 Oct 2001 15:52:48 +0100

Charles,

As you have described the spec states that "that unsolicited data MUST be
sent in the same order as the commands".  This is not the same as
unsolicited data must follow the command associated with it:  For example:

(Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The x in all the
example can be the ITT. It is not the CmdSN.

This is allowed:

  C1 C2 C3 D1 D2 C4 D3 D4

and the target will have to use the ITT to associate the data with the
command.

Matthew

-----Original Message-----
From: Binford, Charles [mailto:[email-masked]]
Sent: Friday, October 12, 2001 2:50 PM
To: [email-masked]
Subject: RE: Addition of CmdSN in Data-out PDU

I have not verify version 8 is still the same, but version 07-97 had a rule
that unsolicited data MUST be sent in the same order as the commands.  

Thus, there is no need for a search on the ITT.  The target just needs to
keep of linked list of I/Os waiting on unsolicited data.  New commands are
added to the tail, any unsolicited data *should* be associated with the I/O
at the head of the list.  The ITT is used as a sanity check and you're done.

What am I missing?

Charles Binford
Pirus Networks
316.315.0382 x222

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

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: "Eddy Quicksall" <[email-masked]>
Date: Fri, 12 Oct 2001 15:34:51 -0400

Matthew,

The statement would also imply the following would be legal, do you agree?

Cx = SCSI Command w/ITT=x, Dxyz = unsolicited data w/ITT=x and DataSN=y and
Final=z

C1 C2 D11 D21 D22 D12F D23F

i.e., the only rule is that the data for an ITT can't come before the
command for the same ITT.

Eddy

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:[email-masked]]
Sent: Friday, October 12, 2001 10:53 AM
To: 'Binford, Charles'; [email-masked]
Subject: RE: Addition of CmdSN in Data-out PDU

Charles,

As you have described the spec states that "that unsolicited data MUST
be
sent in the same order as the commands".  This is not the same as
unsolicited data must follow the command associated with it:  For
example:

This is allowed:

  C1 C2 C3 D1 D2 C4 D3 D4

Matthew

-----Original Message-----
From: Binford, Charles [mailto:[email-masked]]
Sent: Friday, October 12, 2001 2:50 PM
To: [email-masked]
Subject: RE: Addition of CmdSN in Data-out PDU

I have not verify version 8 is still the same, but version 07-97 had a
rule
that unsolicited data MUST be sent in the same order as the commands.

Thus, there is no need for a search on the ITT.  The target just needs
to
keep of linked list of I/Os waiting on unsolicited data.  New commands
are
added to the tail, any unsolicited data *should* be associated with the
I/O
at the head of the list.  The ITT is used as a sanity check and you're
done.

What am I missing?

Charles Binford
Pirus Networks
316.315.0382 x222

-----Original Message-----

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: "Somesh Gupta" <[email-masked]>
Date: Fri, 12 Oct 2001 14:51:15 -0700

Matthew,

Since the unsolicited data does not follow the
command, you need the link list. But since the
unsolicited data must be sent in the same order
as the commands, a link list is enough.

Let us say that you have 8 commands. The ones
for which we expect unsolicted data are marked
as Cnn(ud). And I have marked the unsolicted
data PDUs as UD(nn). The (nn) with data implies
that it is implicit and not actually carried with
the PDU itself.

C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) --->
--> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) --->
--> UD(07) C08(ud) UD(08) --->

After the target receives the command C01, C02, and C03
for which it expects unsolicited data, it puts them in
a link list. It also receives C04 and C05 for which
unsolicited data is not expected and they don't go
on the list. It then receives C06 for which unsolicited
data is expected, and it is added to then end of the list.
Then an unsolicited data PDU is received. It must go
with the command at the head of the list which is C01.
Use the ITT to make sure and you can then take C01 off
the list and so on.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Sent: Friday, October 12, 2001 7:53 AM