Correct. However, in the current aic7xxx code we maintain the queue of
commands to be sent in kernel space, and the controller DMAs those commands
down. So, when this happens, we can easily just pause the sequencer, remove
the commands waiting but not sent yet, update the queue tail position to
reflect the number of commands we removed, then unpause the sequencer after
changing a few flags so the command will get sent untagged instead of
tagged. This assumes that the device rejecting the tagged command will
reject all tagged commands, and hence there won't be any outstanding
commands at the time of the rejection. We make this assumption because,
like you, if a drive randomly rejects tag commands it's horribly broken as
far as I'm concerned and someone else can write a firmware update :)
> I've considered all that and even more. If someone want to take into
> account all compliant and non compliant SCSI device behaviours regarding
> Tagged Command Queueing, I am interested in knowing the real gain compared
> to the needed effort.
I don't take into account all possible behaviours. I make one assumption,
that no device randomly rejects tags, they either accept them or reject
them, and from that point I simply stop tagged queueing on the first reject
I get for a tagged command (although, I do admit, if the reject comes on one
of our ordered Q tags, then I don't blow off tagging completely, just the
ordered tags).
> Only high end SCSI devices really gain advantage of tagged commands and
> they generally behave well enough with this feature. I doubt that
> crappy Jaz devices are really faster with tagged commands and so,
> I am not about to spare time for useless improvements.
The one exception to this, which prompted me to put the code in, was that
certain OEM drive resellers were shipping decent hard drives out with the
DQue bit set. Since the drives were actually capable of tagged queueing,
and high enough performance to benefit from it, this was reasonable.
Especially when you consider that without the code, the driver went into an
abort/reset loop continually resetting the drive because it was failing on
tagged commands. The drives in question were IBM DFS series drives shipped
by Sun and Apple.
--Doug Ledford <dledford@dialnet.net> Opinions expressed are my own, but they should be everybody's.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu