streamlining the sym2 io submission path

streamlining the sym2 io submission path

[Matthew Wilcox]

I've been looking at speeding up sym2's queuecommand method.  In my
current development tree, I've removed most of sym_queue_command()
and inlined the remains into sym53c8xx_queuecommand().  There's some
funny stuff I wouldn't mind some advice with:

We fail the first command to the device if the device is marked as
NOSCAN or the lun is non-0 and the device isn't marked as SCAN LUNS.
I think the first part should be moved to slave_alloc(); it's a little
weird, but supportable.  The second part troubles me a little -- is the
blacklist in the midlayer good enough to handle this, or should I leave
this mechanism in?

The driver currently fails commands sent to the lun of the host adapter.
Is this the correct behaviour?  What should the driver do?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: streamlining the sym2 io submission path

[Christoph Hellwig]

On Wed, Apr 20, 2005 at 12:43:23AM +0100, Matthew Wilcox wrote:
> We fail the first command to the device if the device is marked as
> NOSCAN or the lun is non-0 and the device isn't marked as SCAN LUNS.
> I think the first part should be moved to slave_alloc(); it's a little
> weird, but supportable.  The second part troubles me a little -- is the
> blacklist in the midlayer good enough to handle this, or should I leave
> this mechanism in?

For the first make sure to return -ENXIO from ->slave_alloc, the scsi_scan
code special-cases that one and doesn't print an error.  For the second
I don't care too much.  The midlayer blacklist and if nessecary the
runtime updates to it will handle such devices just fine, but following
them nvram might not be a bad idea either.

> The driver currently fails commands sent to the lun of the host adapter.
> Is this the correct behaviour?  What should the driver do?

The driver will never receice a command for the host adapter (unless it
allocates a scsi_device for the host adapter itself, as e.g. gdth does)