You should define “handle tagging appropriately”. What behaviors of
tagged queueing are you hoping for?
Scsiport ignores the various tag modifiers (head-of-queue,
ordered-queue) - no ordering is imposed based on the tag value. If you
want to strictly control the order of operations, then your filter
driver would have to queue requests itself and impose that order on its
own.
The port driver automatically assigns 8-bit tag values (0, 255 and I
believe 254 aren’t assigned to tagged requests) to SRBs that have the
tagged queuing flag set in them if the device and the HBA indicate that
they support tagged queueing.[1] In general these tags are assigned
across the adapter rather than per-lun due to age-old assumptions in
some of the more popular miniports that tags were per-adapter (and
unfortunately assumptions in a few often imply assumptions in many).[2]
There are also some registry flags that will clear the tagged-queueing
enabled flag from the SRB when it enters the port driver. If these are
set then requests to that lun (or on that HBA, but I think it’s a
per-lun flag) will be sent untagged regardless of what the class-driver
says.
Scsiport will issue multiple requests to the miniport for a particular
lun given some convergence of the following conditions (standard
disclaimers apply … It’s been a couple of years since I’ve had my
hands in this code):
-
The miniport ASKS for another request on that LUN -or-
Completes the only outstanding request for the LUN -or-
The miniport indicates MultipleRequestPerLu [3]
-
There is not an untagged request waiting to run on the device
-
The maximum queue depth hasn’t been reached (this drops when the
device returns queue-full[4]
-
The device doesn’t indicate that it’s busy, or that there’s a CA
condition
I’m sure there are other requirements but that’s the gist of it. Class
driver can enable tagging, but the port driver controls it.
So to answer your questions:
-
As true as the class driver, device and miniport allow it to be.
-
A filter on the PDO between port and class could control whether or
not tagged queuing was enabled for a given request. If you need to
impose ordering then you have to queue requests and send them down one
at a time (scsiport is free to reorder requests as it sees fit, as is
the miniport)
-
(a) would work, (b) might but you’ll only see as many requests as
scsiport hands you at a time.
Good luck,
-p
[1] the HBA & device also have to support/initiate disconnect or tags
are meaningless.
[2] I believe storport lifts this limitation … I don’t know the plans
for doing this for scsiport (ie. It might be documented how to do it
right now, but I don’t know)
[3] Note that this is one of those flags I’ve never fully understood
myself since we no longer used it when I inheritted the code base. I
believe the intention was for controllers that allowed you to batch
multiple commands within the controller where the controller could
determine what command to send next and when as requests completed. I
broke this at one point during Win2k when fixing some of the “scsiport
takes a nap” bugs and I while I presume I or someone else got it working
again, I truly don’t remember.
[4] I think there’s a back off stragtegy for queue-full now so that if
the queue depth is variable your device won’t get choked down to only a
couple of I/O requests at a time.
*******
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chuck Batson
Sent: Monday, June 21, 2004 11:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tagged queuing of CDBs
I’m exploring the idea of directly controlling tagged queuing of custom
SCSI CDBs on certain devices (that have existing port and class drivers)
under Windows 2000 or higher.
* The DDK docs imply that the port driver takes advantage of tagged
queuing automatically when possible. How true is this in practice?
* Is a lower-level filter driver above the port driver able to control
the tagged queuing? Or are the tagged queuing fields of the
SCSI_REQUEST_BLOCK basically ignored above the port driver level and
reset by the port driver?
* A couple years ago Peter Wieland mentioned that pass-through requests
are untagged. Thus it would seem from my limited knowledge that the
only way to get multiple custom SCSI CDBs queued on a single LUN is to
either (a) use a filter driver to send SRBs to the port driver, on the
faith that the port driver will handle tagging appropriately; or (b) if
manual control of tagged queuing is required, write a custom (mini?)port
driver. How accurate is this statement?
Fire away! 
Thanks,
Chuck
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com