document  X3T9.2/90-083
  TO: X3T9.2 Committee (SCSI)

FROM: Gerry Houlder (Seagate)

SUBJECT: Alternative Initiator Control of Reselection

John Lohmeyer's document (X3T9.2/90-062 REV. 2) proposes two new 
messages to implement an initiator control of reselection for 
data transfer function.  I agree with Tom Wickland's paper 
(X3T9.2/90-071) that points out the need for this ability but I 
see a performance disadvantage for John's implementation.  The 
disadvantage is the extra overhead of another message to be 
processed on every command (the TARGET DATA RECONNECTION DISABLE 
message).

I believe the "target reconnection disable" function should be 
implemented as a bit in the control byte of the CDB.  One of the 
four reserved bits can be defined as the TARGET DATA RECONNECTION 
DISABLE bit, with the same function as the TARGET DATA 
RECONNECTION DISABLE message defined by John Lohmeyer.  This 
approach has as much flexibility of using a message but doesn't 
require the overhead of handling another message byte.  The 
control byte must already be transmitted so no additional 
interface overhead is imposed.

Existing SCSI controller chips use "multi-phase combinational 
commands" to greatly reduce the overhead associated with handling 
selection, identify message, and command bytes but the extra 
unexpected message byte will cause them to abort the fast 
sequence and require the target microprocessor to handle the rest 
of the sequence.  The performance penalty for this is huge.  Some 
may argue that new high performance (code word for expensive) 
chips will be able to handle the extra message byte with only a 
microsecond or so of extra time.  Why have even one extra 
microsecond of overhead when it is just as easy to do the same 
thing without any extra overhead?

The only remaining advantage of having the TARGET DATA 
RECONNECTION DISABLE message is to allow the initiator to change 
his mind later; e.g., a long command is sent allowing 
reconnection, the target reconnects and transmits the first part 
of the data, and before disconnection the initiator sticks in 
this message so that the target will not do further data 
reconnections on its own.  If the committee decides that this is 
still a useful operation, the TDRD message can co-exist with the 
TDRD bit in the control byte.  Otherwise, the message is 
redundant and should be eliminated in favor of the bit in the 
control byte.


If the committee accepts this proposal, the changes to Rev. 10C 
of the SCSI draft would be as shown on the next page.


[changes to Table 6-5 are in bold type]

                    Table 6-5: Control Field
===============================================================
 Bit|   7   |   6   |  5   |  4   |  3   |  2   |  1   |  0   |
===============================================================
    |Vendor Specific|   Reserved         | TDRD | Flag | Link |
===============================================================


[The following paragraphs need to be added immediately below 
Table 6-5.  The non-bolded text is added if the TDRD message is 
also defined and left out if it is not.]

A TDRD (Target Data Reconnection Disable) bit of zero indicates 
that the initiator allows the target to reconnect to enter a data 
phase when it is ready.

A TDRD bit of one indicates that the initiator requires all
subsequent reconnections for data transfer on this I/O process be 
done by the initiator instead of the target.  The target may 
reconnect for other purposes but shall not enter a data phase on 
a target reconnection.  If the target implements this option, it 
shall also implement the CONTINUE I/O PROCESS [and TARGET DATA 
RECONNECTION DISABLE?] message[s].  If the option isn't 
implemented, the target shall set CHECK CONDITION status.  The 
sense key shall be set to ILLEGAL REQUEST and other applicable 
sense bytes set as appropriate.

When the target is ready to transfer data for this disconnected I/O 
process, it shall reconnect to the initiator, send an IDENTIFY 
message, optionally send a SIMPLE QUEUE TAG message (if this is 
an I_T_L_Q nexus), send a DISCONNECT message, and go to BUS FREE 
phase.  This connection serves to notify the initiator that the 
I/O process is ready for data transfer.  The initiator may 
reconnect to continue the I/O process as described in the 
CONTINUE I/O PROCESS message (see 5.6._) to do the data transfer.

  IMPLEMENTORS NOTE: The initiator may assert ATN during the 
  DISCONNECT message and send a MESSAGE REJECT message.  In this 
  case the target shall remain connected and enter the data phase 
  to continue the I/O process.