Re: Correct use of ap->lock versus ap->host->lock ?

[Mark Lord <liml@rtr.ca>]

Jeff Garzik wrote:
> Mark Lord wrote:
>> There are definitely other fish to fry elsewhere,
>> but don't discount the effect of "a couple register writes",
>> which are frequently done with readbacks to flush them,
>> at a cost equivalent to several thousand CPU cycles per readback.
> 
> Those numbers are for slower PIO, not MMIO as found on new SATA 
> controllers...
> 
> 
>> This prevents new command issue from overlapping interrupt handling
>> for any ports of the same host.  Again, not a biggie today,
>> but tomorrow perhaps..
>>
>> And still probably not worth the fuss on any hardware that has
>> registers shared across multiple ports (eg. Marvell controllers).
> 
> 
> Remember, I come from the land of networking, where we already see over 
> 500k packets per second.  None of this is new stuff.
> 
> In networking you lock both TX submission (analogy: scsi queuecommand) 
> and TX completion (analogy: completion via irq handler), and we don't 
> see any such problems on multi-port controllers.
> 
> It is not worth the fuss on new SATA controllers, which look just like 
> NIC hardware has looked for a decade -- DMA rings, with a single MMIO 
> write (or write+read) to indicate software has new packets for hardware. 
>  Even at exponentially higher FIS rates, locking doesn't become an issue.
..

The big difference here, is that a single SATA controller in a system
can have up to eight quasi-independent ports.  So when we lock, we block
activity on all 8 interfaces, rather than just the one we care about.

At LSF'08 there was much discussion about the coming 100000 ops/second SSDs,
which exist in the marketplace already.  At some point, this stuff will
matter as much for SATA as it did/does for networking.

Cheers