section 10.8.3.3.4

Bill Galloway BillG at breatech.com
Mon Oct 16 17:03:35 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill Galloway" <BillG at breatech.com>
*
Srinivasan,

I do not agree with some of your changes in 00-384r0.

In your DT DATA OUT error handling your are requiring the target to send the
status IU during the same connection as the bad data IU.  That has never
been the requirement before and should not be now.  We do not require this
in non-packetized and we do not need to require it in packetized.  I can not
think of anything the initiator would do differently, so why mandate that
the target can not go bus free and reconnect later???

The only strict requirement on the target is to stop a "multi" command
sequence so that it does not receive the commands out of order.


Also your are adding a new unwarranted feature for command IUs.  Today
commands are only sent on the FIRST DT DATA OUT phase after a selection.
Why should we add anymore complications to a low performance error recovery
case by allowing the target to go back to DT DATA OUT and troll for more
commands (that the initiator may not even want to send now)??


In your DT DATA IN error handling, I think we agree. I can think of no good
reason to limit how many data stream packets the REQ offset can cover.  I
think the target should be able to send as many REQs as the offset allows
across any number of data stream packets (NOT L_Q packets) and should be
allowed to respond to the ATN condition after any number of data stream
packets.

Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at breatech.com

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