Packetized L_Q IU type field changes

gop at gop at
Wed Dec 15 07:08:23 PST 1999

* From the T10 Reflector (t10 at, posted by:
* gop at
Breaking the stream of commands to send a status is definitely allowed. The
note and figure allow that to happen along with the text your referenced.
The issue is not with sending queue full status but with allowing the
target to do something else to end the command stream. Right now the only
way for the target to end a stream of commands is to issue a queue full
status (or some other status). The question that is being asked is 'Why is
the target restricted in that way?' At this point I cannot think of a good
reason and if no one comes up with one I will probably propose the
restriction be dropped on SPI-3.

Bye for now,
George Penokie

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

Mark_Heath at on 12/15/99 08:41:23 AM

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

> On your last comment you need to look at the note the SPI information
> 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
> 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!!!

I believe the wording of the third paragraph of subclause 14.3.1 suggests
the target is allowed to break a Multiple Command sequence in order to send
SET FULL.  (The wording is "After transferring all the SPI command
unit bytes the target shall change to a DT DATA IN phase and transmit a SPI
status information unit with the status...")  I also agree that there are
places in the standard (such as the one you pointed out) with somewhat
contradictory wording.

In my opinion, a target *must* be allowed to break a sequence of "Multiple
Command" LQ_IU/Command_IU's in order to return TASK SET FULL status.  If
standard does not allow a target to do this, then the standard effectively
requires a target to have practically infinite resources.  Imagine this
scenario:  An initiator selects the target and sends one billion "Multiple
Command" LQ_IU/Command_IU pairs and finally sends a "Single Command"
LQ_IU/Command_IU pair to terminate the sequence.  At this point the target
be required to send TASK SET FULL to most of those billion commands.  In
words, the target would have to somehow remember the LUN and Tag of nearly
billion commands (or 1 trillion, or 100 trillion, or however many commands
initiator sent) in order to send TASK SET FULL to each I_L_Q nexus.

The whole point of TASK SET FULL is to provide the target a mechanism for
"I've run out of resources."  The only way that this mechanism can work is
the target is able to send TASK SET FULL precisely when it runs out of
resources.  Therefore, I think the standard should be modified to clarify
the target is in fact allowed to do so.

Mark Heath

p.s. I used the term "practically infinite resources" in the description
In reality, there is a limit to the number of possible LUN/Tag
The limit is slightly more than a trillion trillion.  This is just a little
beyond the amount of resources that most targets contain.  ;-)

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

More information about the T10 mailing list