Re: [t13] RE: comment on T10 ATA-passthru

Re: [t13] RE: comment on T10 ATA-passthru

[Jeff Garzik]

BTW, can you send me a patch that filters out
SET FEATURES - XFER MODE ?

That should not be executed without driver intervention /
synchronization.

	Jeff



P.S.  Any news on hotplug?

Re: [t13] RE: comment on T10 ATA-passthru

[Andy Warner]

Jeff Garzik wrote:
> BTW, can you send me a patch that filters out
> SET FEATURES - XFER MODE ?
> 
> That should not be executed without driver intervention /
> synchronization.

There are _so_ many commands that can be terminal for
continued communication with the drive, do we really want to
start filtering commands ?

I don't really have a dog in this fight; my personal end
goal is for a drive-test-vehicle, so I'll need to be able
to circumvent any blacklist anyway. I'll happily add a
blacklist, but I'll just as happily add a way around it.

Would it be important/useful to make the pass-thru
stuff a config option ?

Plus, rev 5 of the spec is out now, and rev 6 may be
along soon. We're currently at rev 3 - I'll be wanting
to play catch-up soon. The changes are pretty intrusive,
so heads-up to anyone using it.

> P.S.  Any news on hotplug?

Err. It's got pushed down on my task stack, I have to
pop at least two things off that stack before I can get
back to it.

However, in working through recovery scenarios for
aborted PIO/DMA transfers, it looks like I need to
reset the port, which will interact with hotplug
because I lose drive phy status when I issue reset
via the SATA control regs. Hotplug looks like it
is going to be non-trivial, even though it's not
horribly complicated. My plan is to continue down
the route of seperating HBA init and drive probe.
For adapters that support hotplug (shouldn't all
SATA ?), I plan to just let the hotplug code take
care of drive probing. For HBAs that are brain
dead somehow (perhaps a PATA port ?), I plan to
provide some easy hook that the hba driver can
call during xxx_add_one()[or whatever.] Issues
already identified include flagging a drive that's
absent, and failing any subsequent requests, so
that we don't hang trying to sync a disk that's
not there any more.

Thoughts and advice wrt possible use of outboard
SATA switches and how that will need to interact
with hotplug would be gratefully received.

Post-hotplug, I'm going to be looking at NCQ, care
to share any high-level design decisions that you
(or others) have already taken in that area ?
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: [t13] RE: comment on T10 ATA-passthru

[Jeff Garzik]

On Fri, Oct 29, 2004 at 03:39:53PM -0500, Andy Warner wrote:
> Jeff Garzik wrote:
> > BTW, can you send me a patch that filters out
> > SET FEATURES - XFER MODE ?
> > 
> > That should not be executed without driver intervention /
> > synchronization.
> 
> There are _so_ many commands that can be terminal for
> continued communication with the drive, do we really want to
> start filtering commands ?

It is absolutely required that we snoop commands.

Two main reasons:

* to update device information (dev->id, etc.) that we have cached
  in local data structures

* to trigger hardware reprogramming, necessary to ensure continued
functional operation.

Examples:  a) Promise hardware snoops SET FEATURES - XFER MODE
commands, and reprograms a hardware register based on the taskfile's
contents.  If DMA is active on _other_ ports when this occurs, then data
corruption occurs.  One must make sure that the other ports are paused
before issuing this command.

b) PATA hardware requires programming controller-specific registers to
match the PIO/DMA mode set in the SET FEATURES - XFER MODE taskfile.

c) other random controller-specific oddities for other commands



> Would it be important/useful to make the pass-thru
> stuff a config option ?

When stable, passthru will be unconditionally enabled.

I'm mainly waiting on T10 to standardize the CDB opcode(s).


> However, in working through recovery scenarios for
> aborted PIO/DMA transfers, it looks like I need to
> reset the port, which will interact with hotplug
> because I lose drive phy status when I issue reset
> via the SATA control regs. Hotplug looks like it
> is going to be non-trivial, even though it's not
> horribly complicated. My plan is to continue down
> the route of seperating HBA init and drive probe.
> For adapters that support hotplug (shouldn't all
> SATA ?), I plan to just let the hotplug code take
> care of drive probing. For HBAs that are brain
> dead somehow (perhaps a PATA port ?), I plan to
> provide some easy hook that the hba driver can
> call during xxx_add_one()[or whatever.] Issues
> already identified include flagging a drive that's
> absent, and failing any subsequent requests, so
> that we don't hang trying to sync a disk that's
> not there any more.

Hotplug is definitely non-trivial :)  These are indeed some of the
issues in play.


> Post-hotplug, I'm going to be looking at NCQ, care
> to share any high-level design decisions that you
> (or others) have already taken in that area ?

Most of the code is already written to assume that queueing is
active.  Turning on NCQ in libata is trivial.  Handling errors and
synchronization is less trivial :)

For the controllers that transparently support it, we want to enable
TCQ as well.

	Jeff

Re: [t13] RE: comment on T10 ATA-passthru

[Andy Warner]

Jeff Garzik wrote:
> It is absolutely required that we snoop commands.
> [...]

OK - like I said, it really doesn't make any difference
to me, I'm happy to implement a black/snoop-list. Does
anyone else have constraints/suggestions/comments to
offer ?

Since I'll effectively be implementing a feature I don't
care much about, I'll take all the (constructive) input
available.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: [t13] RE: comment on T10 ATA-passthru

[Andy Warner]

Jeff Garzik wrote:
> [I ask about NCQ ...]
> Most of the code is already written to assume that queueing is
> active.  Turning on NCQ in libata is trivial.  Handling errors and
> synchronization is less trivial :)

I guess I'm a little gun shy here :) Remember, my induction to
hotplug consisted of:

	"That's because libata doesn't call the proper hot-unplug hooks.
	 Call those hooks, and the problem goes away."

I really don't want to hugely underestimate the effort involved.

Things that I can't quite see being in there right now
are the low-level state machine support for queued events,
and data structures and functions required to queue the pending
requests.

The boundary conditions you allude to seem likely to be
a pandora's box. Not the least of which will be ensuring
that queued and non-queued commands never mingle. It is
my understanding that any non-queued command will abort
*all* pending queued commands with unpredictable results
for data in flight.

What (if any) chip/board level driver work can be expected ?
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

libata and queueing (was Re: [t13] RE: comment on T10 ATA-passthru)

[Jeff Garzik]

Andy Warner wrote:
> Jeff Garzik wrote:
> 
>>[I ask about NCQ ...]
>>Most of the code is already written to assume that queueing is
>>active.  Turning on NCQ in libata is trivial.  Handling errors and
>>synchronization is less trivial :)
> 
> 
> I guess I'm a little gun shy here :) Remember, my induction to
> hotplug consisted of:
> 
> 	"That's because libata doesn't call the proper hot-unplug hooks.
> 	 Call those hooks, and the problem goes away."
> 
> I really don't want to hugely underestimate the effort involved.
> 
> Things that I can't quite see being in there right now
> are the low-level state machine support for queued events,
> and data structures and functions required to queue the pending
> requests.
> 
> The boundary conditions you allude to seem likely to be
> a pandora's box. Not the least of which will be ensuring
> that queued and non-queued commands never mingle. It is
> my understanding that any non-queued command will abort
> *all* pending queued commands with unpredictable results
> for data in flight.

Everything is a pandora's box :)  Nobody said storage was easy :)

My advice for any efforts, whether it's NCQ or hotplug or whatever, is: 
  post early, post often.  Design in public first, get the design nailed 
down, _then_ settle in for some testing.

One of the key problems is that a lot of the future directions and 
current methodology isn't written down, so you need to pelt me (CC'ing 
linux-ide, to share the knowledge) with email asking questions.

[side note: anyone is welcome to patch Documentation/DocBook/libata.tmpl 
with new knowledge]


Now, back to queueing specifically...

libata currently relies on the SCSI layer to handle queueing (or lack 
thereof), and to handle arbitration between master/slave in PATA 
configurations.

There is minimal infrastructure in libata for queueing:  32 commands 
(ata_queued_cmd) per ata_device, but that's mainly for storage of 
per-command metadata.

To implement queueing in libata, you'll use the current libata 
per-command infrastructure, and the SCSI mid-layer's queueing 
infrastructure in concert.  The SCSI mid-layer API is used to control 
the queue depth.  For exceptional cases such as error handling and 
non-queue-able commands, you'll return host-busy to the SCSI mid-layer 
from the libata ->queuecommand hook.

Error handling consists of knowing which commands to retry, which to 
fail, and which to partially complete.