Draft Minutes of Parallel SCSI WG - Sept 12, 2000

Elliott, Robert (Hou) Robert.Elliott at COMPAQ.com
Wed Sep 20 08:57:31 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Hou)" <Robert.Elliott at compaq.com>
*
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gene.Milligan at seagate.com
> *
> 
> <<Bill Galloway asked if there was anyone present who wanted to do
> bidirectional data transfers in data group (non-packetized)
> transfers.  No one present supported defining bidirectional 
> data group transfers.>>
> 
>      I think this overstates, perhaps misstates positions. 
> Due to OSD and some known proprietary implementations it is 
> recognized that SAM should not prohibit bi-directional 
> transfers. Bi-directional in this case is referring
> to a single command that results in the transport 
> transferring data in two directions before completion even 
> if at any given time data is transferring in only one 
> direction. At the moment SPI-4 mistakenly prohibits data group
> transfers at the Fast 160 rate. This of course biases the 
> standard against future enhancements of data group 
> transfers. Data group transfers need to be restored for 
> all data rates. But the near term issue was to remove the
> SAM prohibition of bi-directional transfers and then the next 
> step is to decide in due course what if any commands should 
> include bi-directional transfers. Some transports will be 
> more amenable to bi-directional than others but working on 
> bi-directional for data group transfers certainly
> takes a back seat to restoring data group transfers for Fast 160.
> 
>      I think the minutes should be changed to "Bill Galloway 
> asked if there was anyone present who wanted to do 
> bi-directional data transfers in data group (non-packetized) 
> transfers.  No one present proposed defining bi-directional 
> data group transfers at this meeting." or to "Bill Galloway
> asked if there was anyone present who wanted to do bi-directional 
> data transfers in data group (non-packetized) transfers.  No one 
> responded."

The latter sentence is better, as 00-314r1 which I presented 
allows bidirectional commands in non-IU modes.

I haven't decided yet whether to limit them to packetized 
mode in 00-314r2.  If we do limit them, should the drive
reject the command in non-IU mode but accept it in IU mode?
What status and sense code?  Should the CmdDT feature always 
report that the command exists, or should it only do so when 
INQUIRY is being run in IU mode?  It doesn't simplify
00-314 any, although it may simplify testing and 
implementations.

SPI-3 already requires targets to clear their task sets when
IU mode is disabled, so we don't have to worry about a
bidirectional command started in IU mode not being able to 
continue after IU is negotiated off.  By existing rules the
command is terminated.

---
PC: Robert.Elliott at compaq.com
UNIX: relliott at unixmail.compaq.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