WDF Queues - NT Insider May/June

Hello out there!

First of all: Congratulations to another very good issue of the NT-Insider! The article about WDF Queues was really enlightening! Even for me, who never done something KM related, but being curious about the whole thing, and a follower here on the lists!

There is just something missing in my understanding, maybe I got it, but I just want to make sure I got it right.

I take the example from the article, this it:
. A single Read or Write at one time (but they may be parallel), the device must be powered on
. Some IOControls may happen at powered off state
. The UM Components do some inverted call

Would the following setup be ok?

. Default Queue: Parallel, not power managed
. Read-Queue: Sequential, power managed
. Write-Queue: Sequential, power managed
. IOControl-Queue: Sequential, not power managed
. InvCall-Queue: Manual, not power managed (can manual queues be pm?)

After I’ve setuped my Queues, an IRP arrives in the Default-Queue (all request arrive there, or not?):
. Based on the operation and IOControl-Code (for InvCall), I insert the request in either one of the queues
. This action would *not* cause the Request to be completed, because it’s inserted into another queue
. This action would *not* cause the device to be powered on, because the Default-Queue is not PM
. If it’s a read or write, KMDF would power the device on, if needed, because they are PM
. Otherwise the device will not power on, because the queues are not PM
. In every other than the InvCall queue, the request gets dispatched to the queue-handler callback (EvtIoRead/EvtIoWrite) sequentially

If this OK so far, the following questions are left:
. Now e.g. in the “Read-Queue”, an request arrives, I talk to my device, and wait for an interrupt which signals completion. So Within the queue callback, I just initiate the IO-Request. How can the ISR (or maybe the DPC) can dequeue the Request, so that it gets completed? Or is it the other way round? I complete it, and so it gets removed from the queue?
. Can you point to an DDK Sample which shows some code?

Thanks!
GP

Nobody?

GP

“G?nter Prossliner” schrieb im Newsbeitrag news:…
Hello out there!

First of all: Congratulations to another very good issue of the NT-Insider! The article about WDF Queues was really enlightening! Even for me, who never done something KM related, but being curious about the whole thing, and a follower here on the lists!

There is just something missing in my understanding, maybe I got it, but I just want to make sure I got it right.

I take the example from the article, this it:
. A single Read or Write at one time (but they may be parallel), the device must be powered on
. Some IOControls may happen at powered off state
. The UM Components do some inverted call

Would the following setup be ok?

. Default Queue: Parallel, not power managed
. Read-Queue: Sequential, power managed
. Write-Queue: Sequential, power managed
. IOControl-Queue: Sequential, not power managed
. InvCall-Queue: Manual, not power managed (can manual queues be pm?)

After I’ve setuped my Queues, an IRP arrives in the Default-Queue (all request arrive there, or not?):
. Based on the operation and IOControl-Code (for InvCall), I insert the request in either one of the queues
. This action would not cause the Request to be completed, because it’s inserted into another queue
. This action would not cause the device to be powered on, because the Default-Queue is not PM
. If it’s a read or write, KMDF would power the device on, if needed, because they are PM
. Otherwise the device will not power on, because the queues are not PM
. In every other than the InvCall queue, the request gets dispatched to the queue-handler callback (EvtIoRead/EvtIoWrite) sequentially

If this OK so far, the following questions are left:
. Now e.g. in the “Read-Queue”, an request arrives, I talk to my device, and wait for an interrupt which signals completion. So Within the queue callback, I just initiate the IO-Request. How can the ISR (or maybe the DPC) can dequeue the Request, so that it gets completed? Or is it the other way round? I complete it, and so it gets removed from the queue?
. Can you point to an DDK Sample which shows some code?

Thanks!
GP

----------

“. Now e.g. in the “Read-Queue”, an request arrives, I talk to my device, and
wait for an interrupt which signals completion. So Within the queue callback, I
just initiate the IO-Request. How can the ISR (or maybe the DPC) can dequeue the
Request, so that it gets completed? Or is it the other way round? I complete it,
and so it gets removed from the queue?
. Can you point to an DDK Sample which shows some code?”

– you can queue the incoming request from framework to another manual queue and can dequeue the request from dpc or another routine and can complete that request. There are APIs provided in wdk for that like to operate on queue WdfRequestXXX()

Günter Prossliner wrote:

Nobody?

I’m afraid I got lost in your description and passed it by.

If this OK so far, the following questions are left:
. Now e.g. in the “Read-Queue”, an request arrives, I talk to my device, and wait for an interrupt which signals completion. So Within the queue callback, I just initiate the IO-Request. How can the ISR (or maybe the DPC) can dequeue the Request, so that it gets completed? Or is it the other way round? I complete it, and so it gets removed from the queue?

After you submit your request to the device, you will need to put the
request in a safe place (like a device context structure) return. Then,
your DPC can pull the first request from that place and complete it.

It would be convenient to use a manual queue for that, because that
makes it cancel-safe, but when you put the request into another queue,
the framework will pop another request from the read queue and send it
to your read dispatch routine.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks. We here at OSR appreciate it.

Me too… There are just sooo many things I want to point out about your note, which included so very much stuff. It’s a lot easier to answer when questions are well thought-out and very specific.

Well, whatever.

Several points:

  1. You can’t complete Requests from an ISR (IRQL too high), so it’ll HAVE to be your DPC

  2. You definitely want to remove the Request from the Queue before you complete it.

  3. As Tim said, the disadvantage of “parking” in-progress requests on a manual queue is that forwarding a Request to a Queue is one of the triggers for the Queue from which the Request originated to present you with a new Request. This is sometimes desirable, and other times not so much. I’ve suggested, to no avail, a Queue Config option that’d allow you to change this behavior (on a target Queue basis) but, so far, no luck. So, if you don’t want to trigger another Request being presented, you can keep the Request Handle of the active Request in your Device Context, for example.

Did that answer your questions? In the scenario you described above, what would you use the Default Queue for??

Peter
OSR

What about pausing the queue before forwarding and the restarting when you complete the parked request as a workaround ? I totally understand the complexity and maintainability of the suggestion, but if you absolutely need it…

d

debt from my phone

-----Original Message-----
From: xxxxx@osr.com
Sent: Monday, June 27, 2011 12:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF Queues - NT Insider May/June

Thanks. We here at OSR appreciate it.

Me too… There are just sooo many things I want to point out about your note, which included so very much stuff. It’s a lot easier to answer when questions are well thought-out and very specific.

Well, whatever.

Several points:

  1. You can’t complete Requests from an ISR (IRQL too high), so it’ll HAVE to be your DPC

  2. You definitely want to remove the Request from the Queue before you complete it.

  3. As Tim said, the disadvantage of “parking” in-progress requests on a manual queue is that forwarding a Request to a Queue is one of the triggers for the Queue from which the Request originated to present you with a new Request. This is sometimes desirable, and other times not so much. I’ve suggested, to no avail, a Queue Config option that’d allow you to change this behavior (on a target Queue basis) but, so far, no luck. So, if you don’t want to trigger another Request being presented, you can keep the Request Handle of the active Request in your Device Context, for example.

Did that answer your questions? In the scenario you described above, what would you use the Default Queue for??

Peter
OSR


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hello Guys!

Thank you very much for your responses. Now it’s clearer for me! I think the time has come to checkout the samples and do some experiments!

Me too… There are just sooo many things I want to point out about your note,
which included so very much stuff. It’s a lot easier to answer when questions
are well thought-out and very specific.

Ok, next time I’ll try to be more specific. And I will point out what the question exactly is!

Thanks again!
GP