Re: [PATCH 09/13] sata_mv ncq Use DMA memory pools for hardware memory tables

[Mark Lord <liml@rtr.ca>]

Jeff Garzik wrote:
> Mark Lord wrote:
>> Jeff Garzik wrote:
>>> Mark Lord wrote:
..
>> Bigger stuff that I'm deferring for 2.6.26:
>>
>>  -- Port multiplier support (though this does look rather simple..)
>>  -- power management support
>>  -- ATAPI
> 
> I'm interested to see this :)
..

Heh.. me too, actually.  :)

>>  -- IRQ Coalescing
> 
> Most "modern" SATA has some form of this, but I've yet to see any 
> benefit.  I've dealt with interrupt (packet) rates of well over 500k/sec 
> in network land, and IMO the overhead in storage, even with tiny 
> operations, is really small in comparison.
> 
> So, I'm not sure its worth the latency penalty...  at least as turned on 
> by default.
..

I agree.  It should default to off, and perhaps have some /sys/ attributes
to enable/tune it.  Or something like that.

The theoretical value is apparently for situations like writing to RAID1.
The write isn't really "complete" until all drives ACK it,
so with IRQ coalescing it may behave more like NAPI than one I/O per IRQ.
And NAPI is apparently a win under heavy load for network, so.. we'll see.

The vendor wants it in the driver, and I think it will be good to have it
there so we can play with and tune it -- to find out for real whether it has
worthwhile value or not.  But yes, the default should be "off", I think.

>>  -- Target Mode support (interfaces yet to be defined)
> 
> I would assume this would be along the lines of the SCSI target mode stuff.
..

Ah, now there's a starting point.  Thanks.

>>  -- TCQ support: would be good in general for libata on smart hosts,
>>      but I'm not sure of the impact on libata EH processing.
> 
> Agreed, it would be nice to support host queueing controllers.
> 
> However, specifically for TCQ, it was rather poorly conceived.  For most 
> controllers (mv, broadcom/svw, others) an error will stop the DMA 
> engine, and you perform recovery in software.  All well and good, but 
> figuring out all the states possible during recovery is non-trivial (I 
> looked into it years ago).  Its just messy.
..

So is NCQ EH, but we manage it.  I wonder how similar (or not) the two are?

I've done host-based TCQ several times now, and EH can be as simple as:

"when something goes wrong, just reset everything, and then re-issue the
commands one at a time, doing per-command EH normally.  Then resume TCQ."

That's dumb, but works extremely reliably.

Cheers