scsipi mid-layer, tagged queueing, and ciss(4)

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

While recently working on a performance issue with the Compaq/HP 
SmartArray adapter, ciss(4),  I found out something about the NetBSD 
scsipi mid-layer and tagged queueing that I had been unaware of for the 
last 9 years.

Almost 2 years ago, Anders Magnusson was looking into the ciss(4) driver 
(http://mail-index.netbsd.org/tech-kern/2008/11/30/msg003704.html), and 
found that only one command was being queued at a time.  The intial 
discussion in that thread pointed to a bad setting for adapt_max_periph, 
but my recent testing showed that even with that corrected, it was still 
only queueing one command at a time per device.

Digging deeper into the sd(4) queueing as well as the scsipi(9) queuing 
lead me to the culprit - the scsipi mid-layer queueing will only send one 
command to the adapter layer if the command is untagged.  The scsipi 
mid-layer will only use tagged queueing if the adapter requests it [this 
was the part I had been unware of, since it hadn't been an issue during 
that time].  The ciss(4) driver had a comment about this, but neither the 
person who ported the driver nor I realized the impact of not implementing 
this function.

Attempting to fix the ciss(4) driver to notify the scsipi(9) mid-layer to 
use tagged queueing failed.  The SmartArray is buggy or incomplete.  It 
does report the CmdQue bit in the flags3 field of the inquiry, but leaves 
the ANSII value in the version field 0 - which indicates the flags3 field 
isn't present.  The scsipi layer doesn't check the flags3 value because 
the ANSII value is < 2, and thus doesn't set the tagged queueing 
capability for the device.  When the adapter requests tagged queueing, 
the scsipi layer happily ignores the tagged queueing request and continues 
using untagged commands.

I am able to force the tagged queueing capability, but it involved using 
scsipi_lookup_periph() to lookup the scsipi_periph structure and 
explicitly setting the PERIPH_CAP_TQING in periph_cap.  After that,
ciss(4) can request enabling tagged queueing and I am able to multiple 
command queued.

My only question would be if using that scsipi(9) function like that is 
"proper" usage of that function.  An alternative method I think I had 
tried prior to that was to check if PERIPH_CAP_TQING was enabled in 
periph_cap each time the ciss(4) driver queued a scsi command (since it 
has the scsipi_periph address available in xs_periph), but that involves 
testing on each command.

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA