Packetized multiple command information units?
Bruce.Leshay at quantum.com
Wed Mar 17 05:05:26 PST 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* Bruce Leshay <Bruce.Leshay at quantum.com>
In SPI-3 packetized protocol, following selection the initiator may send an
SPI_L_Q packet of type "multiple command",
which indicates that after the following data packet (containing the CDB),
the initiator has another command packet to send.
This packet could also be a "multiple command" type, and this sequence can
presumably go on indefinitely.
I don't see any description of how the target can get back in control. Two
situations immediately came to mind, there
are probably more:
1. The target doesn't have any buffer space for additional commands.
2. The target has data available (i.e. a cache hit) for a command and wants
to immediately return the data.
(The target could do this after all the commands are received, but its far
easier for him to maintain context if he
simply returns data for the command he just received, and then goes on from
It appears from the spec that the target could go bus free after receiving a
command packet, even one of "multiple
command" type, but certainly we'd like the alternative of instead receiving
write data or sending read data for one or
more of the commands received, without a disconnect/reselect sequence.
Currently it seems this is only possible
if the target can first receive all the commands the initiator wants to
Perhaps there should be a method for the target to "suspend" the sending of
command packets; he could even
remember that the initator has more commands to send, and then "somehow"
tell the initator to resume sending
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10