Re: SATA Target mode & libata

[Jeff Garzik <jeff@garzik.org>]

On Thu, Nov 08, 2007 at 03:49:17PM -0500, Mark Lord wrote:
> Jeff Garzik wrote:
> >On Thu, Nov 08, 2007 at 03:19:52PM -0500, Mark Lord wrote:
> ..
> >>MMmm..  I wonder what the most common use case is for target mode?
> >>
> >>Everybody I've dealt with thus far uses it as a high-speed local comms 
> >>interface,
> >>which would suggest that it might be done as a network interface 
> >>(ethernet emulation).
> >>
> >>But that would confusingly go across driver subsystems,
> >>despite that this is how it actually is used.
> >
> >The low-level driver itself will just be a dumb DMA send/receive engine,
> >with submit/completion APIs highly similar to the existing ones.  Then
> >you can easily provide a network interface interface (not a typo) on top
> >of that.
> ..
> 
> The obvious BIG difference is that in host mode, *we* initiate 
> communcations,
> whereas in target mode, it has to just sit there waiting for a host to say 
> something.
> 
> That's a pretty big change from how libata operates today,
> in just about every respect.

Not at all -- both initiator and target modes have the exact same tasks:  
1) send stuff to hardware, 2) receive hardware responses.

On modern SAS/SATA hardware, you have both command and response queues.

On modern SATA hardware, you have command queue and a received FIS list,
which provides essentially the same services.

Thus SATA target mode will simply need a "here is data I just received
from the wire" hook, and the rest of the infrastructure already exists.

Target mode will re-use ->qc_issue, and need a new ata_receive_fis()
function for asynchronously received FIS's (H2D FIS, etc.)

	Jeff