Wording issue with SPI-4 rev. 8

Elliott, Robert Robert.Elliott at COMPAQ.com
Wed Jan 2 11:08:23 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
*
Comments inline...

> -----Original Message-----
> From: Richard Moore [mailto:richard.moore at qlogic.com]
> Sent: Wednesday, January 02, 2002 12:42 PM
> To: t10 at t10.org
> Subject: RE: Wording issue with SPI-4 rev. 8
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Richard Moore" <richard.moore at qlogic.com>
> *
> Now that QAS is supported for non-IU devices, what is the best way
> to interpret the QAS_REQ bit?
> 
> Does it mean, "I will participate in QAS", or does it mean, "I will
> accept (as an initator) or generate (as a target) QAS REQUEST
> messages"? Or maybe, "I will respond to a selection/reselection from
> a QAS winner?"

Because the bit is I_T based:

For an initiator port, QAS_REQ=1 means "I can participate in QAS" to 
open connections to this target port.  QAS_REQ=0 means only normal
arbitration will be used for opening connections to this target port.

For a target port, QAS_REQ=1 means "I can participate in QAS" to 
open connections to this initiator port. QAS_REQ=0 means only normal
arbitration will be used for opening connections to this initiator port.

For a target port, IU_REQ=1 and QAS_REQ=1 means "I will generate 
QAS REQUEST messages" after talking to this initiator port.

For a target port, IU_REQ=0 and QAS_REQ=1 means "I will not generate 
QAS REQUEST messages" after talking to this initiator port.

The initiator port's own behavior doesn't change based on the
combination
of IU_REQ and QAS_REQ.

> The first meaning doesn't seem very useful. Devices shouldn't need to
> advertise whether or not they will participate, and even if they did,
> there shouldn't be a need for this to be established separately with
> each device on the bus. What if the initiator sets QAS_REQ, and the
> target clears it in response? The initiator should still be allowed
> to participate in QAS. Also, if the initiator clears QAS_REQ, the
> target is forced to respond with the bit cleared, but the 
> target should
> still be allowed to participate in QAS if it is capable of it.

It is useful to confirm that every port on the bus can participate
in QAS, so you don't have to worry about starving non-QAS ports.
If any target negotiates QAS_REQ off, the initiator may choose to
turn off QAS everywhere rather than forcibly create occasional bus 
free conditions (as described in 10.4.3).

> I would think either the second or third interpretation is more likely
> to be useful. And the second interpretation is almost redundant, since
> QAS REQUEST messages are not allowed except at the end of an IU-mode
> connection (though the bit could be cleared by an IU-capable initiator
> to tell an IU-capable target not to send QAS REQUEST messages).
> 
> The third interpretation would probably be the most useful, since some
> legacy devices might not respond to selections/reselections which are
> not preceded by a BUS FREE/ARBITRATION phase sequence. In this
> interpretation, one device can tell another device not to use QAS to
> (re)select the first device. In this interpretation, there is no
> ambiguity about when a device may participate in QAS (it may do so
> to select/reselect a device that sent QAS_REQ = 1), and there is
> no ambiguity about when a target may send a QAS REQUEST message (it
> may do so anytime it disconnects from an initiator that sent QAS_REQ =
> 1).
> 
> The first interpretation is the one with the least utility (and most
> ambiguity). Unfortunately, this interpretation is the one specified in
> SPI-4. This interpretation (as well as the third interpretation) does
> in fact require two lines in Table 11 for each transfer mode.
> 
> In the case of the second interpretation, devices not supporting IU
> mode should never send or receive a QAS REQUEST message, so the
> non-IU modes would never be combined with a QAS_REQ bit of 1.
> 
>  -- Richard Moore
>     QLogic Corp.
> 
> 
> -----Original Message-----
> From: Elliott, Robert [mailto:Robert.Elliott at COMPAQ.com]
> Sent: Friday, December 28, 2001 2:46 PM
> To: t10 at t10.org
> Subject: RE: Wording issue with SPI-4 rev. 8
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert" <Robert.Elliott at compaq.com>
> *
> I agree that the two tables conflict - when the offset is 00h, are the
> transfer period factor and protocol options ignored or invalid?
> 
> In Rev 7 and in 01-131r4, table 11 listed the transfer period 
> factor as
> 00h - FFh in this case, implying it is completely ignored.  Rev 8
> changed the 00h to 0Ah but still has a range.  Some letter ballot
> comment must have asked for the 0Ah change.
> 
> The protocol option bits, however, did not have "0 or 1" to indicate
> they are ignored.  They should all (except QAS_REQ) be "0 or 1" if we
> want them ignored. If we want them cleared, the table 7 change you
> suggest makes sense.
> 
> Remember that QAS is supported without Information Units.  Non-IU
> targets may participate in QAS generated by other targets; they just
> won't generate QAS_REQUEST messages themselves.  Thus there 
> are two rows
> in table 11 for QAS and non-QAS asynch modes.
> 
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott at compaq.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