[t13] T10/04-262r0

Curtis Stevens curtis.stevens at wdc.com
Thu Aug 12 15:39:17 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Curtis Stevens" <curtis.stevens at wdc.com>
*
Jeff

My point is that the information is available to the bridge when the CDB is
received.  I do not think we want to get into specifying the intervening
layers, there are many possible models.  Software-wise, there is no
difference between PIO multiple and PIO.  In both cases the ATA host needs
the DRQ block size.  This will tell him how many blocks/interrupt to
transfer.

I also do not believe the transport can be separated from the CDB because
this has the transfer length in addition to the direction.  While I could
place the protocol field in the CDB, there is no room for the length.  The
ATA host also needs this information to properly complete a PIO transfer.
For DMA transfers, this information may also be necessary for buffer size
allocation, although some implementations could do it without buffers.

The reason I included the goals is that, given the applications I stated,
queuing is not required.  I am a member of the drive product team and
understand the limitations.  However, support of queuing would require
asynchronous status notification by the bridge to the application.  I don't
think we really need to go there at this time.  If this pass-through becomes
wildly successful and starts to be used in a performance environment, then
we can upgrade it to provide more capability.  

It is not the intention of this proposal to support ATAPI.  More information
would be required...

The DMA vs PIO and DRQ size are provided by the client application.  This
information in combination with a direction bit, also provided by the
client, gives you the available protocols.


------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Dr.  #C 214-D
Lake Forest, Ca. 92630
 
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at wdc.com

 -----Original Message-----
From: 	Jeff Garzik [mailto:jgarzik at pobox.com] 
Sent:	Thursday, August 12, 2004 2:55 PM
To:	Curtis Stevens
Cc:	t10 at t10.org; Forum at t13.org
Subject:	Re: [t13] T10/04-262r0

Curtis Stevens wrote:
> This message is from the T13 list server.
> 
> 
> Jeff
> 
> 	I think you were actually looking at T10/04-262r0...
> 
> 1. I don't think this addresses queuing very well.  In the scope I have
> excluded queing from the support.  That does not mean that it can not be
> made to work...
> 2. I agree with you.  However, I do not think the CDB can be separated
from
> the transport.  The transport has direction, transfer size, and other
useful
> bits of information.  I included the DMA bit because an ATA host need to
> know to use DMA or PIO to transfer the data.  I have also included the DRQ
> block size for PIO transfers.  I think that gives you all the information
> you need to do the transfer.  That being said, if it would make things
> easier to use,  I can remove the DMA bit in favor of a field that specs
> protocol.  What do others think?

Fundamentally, the command protocol is tied to the command opcode being 
executed, not the transport.

The transport merely implements the command protocol.  This fact has 
remained true from the oldest PATA controllers to the newest SATA 
controllers (ones not yet on the market).

Without an explicit command protocol field, the following information is 
missing:
PIO versus PIO-Mult versus ATAPI PIO
DMA versus TCQ DMA versus NCQ DMA versus ATAPI DMA

A single byte, command protocol, can provide all this information and 
more.  With command protocol byte, your CDB is "future proof":  you 
don't need to specify additional bit flags for DMA, PIO Mult, TCQ, NCQ, 
etc.  A command protocol byte automatically takes queueing into account.

[personal note:  any design that doesn't take TCQ/NCQ into account is, 
IMO, automatically outdated.  Ask your drive guys ;-)]

In the implementation of the low-level driver, all this information is 
required, and all this information is independent of transport.  For 
known ATA commands, this missing information can be provided by a lookup 
table.  For unknown (vendor reserved) commands, this information must be 
specified by the client app _somewhere_, since the low-level driver 
cannot know it.

	Jeff




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