Packetized multiple command information units?

gop at us.ibm.com gop at us.ibm.com
Wed Mar 17 06:48:12 PST 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* gop at us.ibm.com
*
Burce,
The way the target can stop the stream on commands is to go DT DATA IN
phase and send an LQ IU with a type of status followed by a Status IU with
the status field set to TASK SET FULL. From there the target can proceed to
any other packetized phase.
You are correct in that the target could also go bus free after receiving
any of the commands, but, as you stated, that is not a very inefficient way
to go. The bus free was intended to allow the target the option of
disconnecting after the command stream is complete.
The idea of restarting the stream at a later time is interesting but I
don't see any good way to do that. The main problem is that the only LQ
types the that comes from the initiator are the command types and the
target has to know when those are coming so it can properly decode them.
The only time that occurs is on the initial connection when the target
knows it was selected therefore it will be getting commands.

Bye for now,
George Penokie

Dept PPV  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880




Bruce Leshay <Bruce.Leshay at quantum.com> on 03/17/99 07:05:26 AM

To:   "'T10 at symbios.com'" <T10 at Symbios.COM>
cc:    (bcc: George Penokie/Rochester/IBM)
Subject:  Packetized multiple command information units?





* 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
there.)

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
send.

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
commands?

                              Bruce Leshay
                              Quantum Corporation
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com



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