Packetized L_Q IU type field changes

gop at us.ibm.com gop at us.ibm.com
Tue Dec 14 15:22:38 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
Bill,
I agree with you that the cleanest method is to send status.

The reason to bit bucket the information after the L_Q IU is to keep this
change consistent with the paths defined in the current SPI-3. If you look
at the SPI information unit sequence during initial connection figure in
section 14.2 you will see there is no path from the L_Q IU to the L_Q
IU/Status IU. I would prefer not to create one if possible at this late
date as I may effect implementations.

On your last comment you need to look at the note the SPI information unit
sequence during initial connection figure in section 14.2 which states
'Shall only occur if the SPI L_Q information unit type field indicates a
type of last command.'  If you look at which outputs from the DT DATA OUT
phase are allowed you will see that only the L_Q IU/Status IU, MESSAGE OUT,
and MESSAGE IN (although there is an error in that QAS should not be
allowed) are allowed. The question about whether or not that restriction
should be there in the first place is open for debate and needs to be
decided by T10. So now it looks like we have both kicked the hornets
nest!!!

Bye for now,
George Penokie

Dept Z9V  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880



"Bill Galloway" <BillG at breatech.com> on 12/14/99 04:05:12 PM

Please respond to BillG at breatech.com

To:   George Penokie/Rochester/IBM at IBMUS, t10 at t10.org
cc:
Subject:  RE: Packetized L_Q IU type field changes




* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill Galloway" <BillG at breatech.com>
*
George,

1) sounds fine.

2) I do not want to make it complicated but... If the target just goes bus
free
the initiator may think that the target did the requested action. I think
that
returning a status LQ is best. I do not see why the target has to take ANY
data
with the bogus LQ.

While we are talking about the TYPE field.... You said in Rochester that
you
believed that a target is required to honor the "Multiple Command" type.  I
do
not see any words that require this. The way I read the current version of
the
SPI, this type is an advisory to the target that the initiator has more
commands but the target can ignore this advisory. I cannot find any words
prohibiting the target from breaking a command stream with a QUE FULL or
going
bus free after a command just because it feels like it.

Now that I have kicked the hornets nest let me say that I see nothing wrong
with it being only an advisory to the target.

Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at breatech.com

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of
gop at us.ibm.com
Sent: Tuesday, December 14, 1999 2:03 PM
To: t10 at t10.org
Subject: Packetized L_Q IU type field changes


* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
During a review of the TYPE field in the L_Q IU a few issues were pointed
out that should be resolved in SPI-3.

1) The current wording in the description of the type codes of last
command, multiple command, and status  is:'The IUCRC INTERVAL field shall
be set to zero.' This is correct but the first thing the tester guys want
to do is set the IUCRC INTERVAL to a non-zero value to see what will
happen. And with no help from the standard I am sure there will be several
responses depending on who implemented it. I would like to suggest the
wording be changed to: 'The IUCRC INTERVAL field shall be set to zero and
ignored by the target.'

2)There is no wording that tells what to do in the case where an invalid
type code is sent to a target (This would be another test case that would
be tried by our tester friends). I have two suggestions as to what should
be the response and we need to pick one:

-Bring out the big hammer and go bus free.
-Bring out the little hammer and, after dumping all the bytes for the
unidentified IU the follows the L_Q IU (remember in this case the iuCRC is
good so there is a valid length in the L_Q IU and the target is still
required to transfer that number of bytes before doing anything else except
bus free) the target would change to the DT DATA IN phase and send a L_Q
IU/Status IU with the RSPVALID bit set and the packetized failure code set
to 02h (or a newly defined code). If we use the 02h it's definition would
have to be changed from 'SPI command information unit fields invalid' to
'SPI command or SPI L_Q fields invalid'. Or we define a new code xxh that
would be defined as SPI L_Q information unit fields invalid.

Any comments??

Bye for now,
George Penokie

Dept Z9V  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list