Packetized L_Q IU type field changes

Bill Galloway BillG at breatech.com
Wed Dec 15 08:15:36 PST 1999


* 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

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of
Mark_Heath at notes.seagate.com
Sent: Wednesday, December 15, 1999 8:41 AM
To: gop at us.ibm.com
Cc: t10 at t10.org
Subject: RE: Packetized L_Q IU type field changes


* From the T10 Reflector (t10 at t10.org), posted by:
* Mark_Heath at notes.seagate.com
*

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

I believe the wording of the third paragraph of subclause 14.3.1 suggests that
the target is allowed to break a Multiple Command sequence in order to send
TASK
SET FULL.  (The wording is "After transferring all the SPI command information
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 other
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 the
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
would
be required to send TASK SET FULL to most of those billion commands.  In other
words, the target would have to somehow remember the LUN and Tag of nearly one
billion commands (or 1 trillion, or 100 trillion, or however many commands the
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
saying
"I've run out of resources."  The only way that this mechanism can work is if
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 that
the target is in fact allowed to do so.

Regards,
Mark Heath


p.s. I used the term "practically infinite resources" in the description above.
In reality, there is a limit to the number of possible LUN/Tag combinations.
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 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