Packetized L_Q IU type field changes

gop at us.ibm.com gop at us.ibm.com
Wed Dec 15 11:48:57 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
Gerry,
The current rules do not allow a target to disconnect (remember in
packetized that means going bus free) if the L_Q IU type is set to multiple
command. That rule is specified by the little 1 after the Bus Free label
next to the arrow out of the DT DATA OUT phase in the 'SPI information unit
sequence during initial connection' figure.
That 1 states: Shall only occur if the SPI L_Q information unit TYPE field
indicates a type of last command.

I'm not sure where this idea comes from that the only status allowed at
this point is a QUEUE FULL status. That is not the case, SPI-3 allows any
status to be reported after breaking the command stream, in fact it does
not actually require that the target send status for the I_T_L_Q nexus of
the last command received, only that it send status. SPI-3 also allows any
number of operations to happen after the L_U IU/Status IU pair is sent.

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



Gerry_Houlder at notes.seagate.com on 12/15/99 10:56:41 AM

To:   t10 at t10.org
cc:
Subject:  RE: Packetized L_Q IU type field changes




* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry_Houlder at notes.seagate.com
*
Maybe I am missing something, but the target doesn't have to break the
'multiple
command' stream with a QUEUE FULL status. Can't it just accept one multiple
command SPI L_Q, accept the command packet, then disconnect if it doesn't
want
to take any more commands? The more difficult case occurs with even a 'last
command' SPI L_Q when the target can't accept even one command, therefore
it
must return QUEUE FULL status.

I agree that if the initiator can tolerate a sequence of:
(a) outbound SPI L_Q with command type,
(b) inbound SPI L_Q with status type,
(c) inbound status packet with QUEUE FULL status;

then a sequence where the inbound status packet is CHECK CONDITION (because
the
target sees an illegal SPI L_Q packet) should also be allowed.





"Bill Galloway" <BillG at breatech.com> on 12/15/99 10:15:36 AM

Please respond to BillG at breatech.com

To:   Mark Heath at Seagate, gop at us.ibm.com
cc:   t10 at t10.org (bcc: Gerry Houlder)

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>
*
Mark,

The Note that George pointed out does allow the target to break a "multiple
command" sequence with status. It just cannot break it for any other
reason.  I
can imagine other reasons that a target may want to break the stream. It
may
have a buffer congestion problem and needs time to get previous commands
out of
the protocol chip (no the same as queue full). It may have data already
staged
for a command and really needs to send the data NOW. If the initiator has
to
handle the broken stream case for status it would seem that it could handle
it
at other times as well.


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



*
* 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