Jake Oshins posted in October some rules for using WDFQUEUEs in KMDF
drivers. For people just getting rolling in KMDF, it is well worth the
trouble to consider carefully how you can exploit WDFQUEUEs, because
they really can make your life easier.
I’ll give you an example. I have a KMDF driver. My first
implementation had a default parallel queue, with two serial queues for
read requests coming in for two different namespace names. Several of
my queue callbacks did nothing but forward to another queue. I then had
holding pens for WDFREQUESTs in various stages of processing in three or
four different cases. This proved to be a nightmare; I did the
cancellation thing wrong in at least two different ways, and cleanup was
a mess.
This week, I had an “aha” moment. I reorganized it all. For my needs,
the serial queues weren’t really helping all that much; what I really
needed was a manual queue with a “new request arrived” notification,
something that a WDFQUEUE can do. Plus, since they are searchable by
file object, I was able to replace the two serial queues with a single
manual queue. I then added two more manual queues for my in-process
requests, and even though neither of them will ever have more than one
request in them, the simple fact that I can stop worrying about
cancellation has simplified the code in the driver measurably.
So, instead of three queues, four request holders, and some ugly
interlock and cleanup code, I have four queues and much simpler
processing. Queues are the key.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
So it’s not clear to me from reading this whether you thought my post helped
or hurt. 8^)
I’m curious about your solution, though. In my code, I’ve often found that
putting an in-process request back into a queue complicates things because
it becomes cancellable again, and in a way that’s hard to track. Does your
code care if the partly processed request disappears from a queue?
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Jake Oshins posted in October some rules for using WDFQUEUEs in KMDF
> drivers. For people just getting rolling in KMDF, it is well worth the
> trouble to consider carefully how you can exploit WDFQUEUEs, because
> they really can make your life easier.
>
> I’ll give you an example. I have a KMDF driver. My first
> implementation had a default parallel queue, with two serial queues for
> read requests coming in for two different namespace names. Several of
> my queue callbacks did nothing but forward to another queue. I then had
> holding pens for WDFREQUESTs in various stages of processing in three or
> four different cases. This proved to be a nightmare; I did the
> cancellation thing wrong in at least two different ways, and cleanup was
> a mess.
>
> This week, I had an “aha” moment. I reorganized it all. For my needs,
> the serial queues weren’t really helping all that much; what I really
> needed was a manual queue with a “new request arrived” notification,
> something that a WDFQUEUE can do. Plus, since they are searchable by
> file object, I was able to replace the two serial queues with a single
> manual queue. I then added two more manual queues for my in-process
> requests, and even though neither of them will ever have more than one
> request in them, the simple fact that I can stop worrying about
> cancellation has simplified the code in the driver measurably.
>
> So, instead of three queues, four request holders, and some ugly
> interlock and cleanup code, I have four queues and much simpler
> processing. Queues are the key.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
On Tue, Jan 09, 2007 at 09:38:29PM -0800, Jake Oshins wrote:
So it's not clear to me from reading this whether you thought my post helped
or hurt. 8^)
Oh, it helped. More than anything, it got me thinking more about queues.
I'm curious about your solution, though. In my code, I've often found that
putting an in-process request back into a queue complicates things because
it becomes cancellable again, and in a way that's hard to track. Does your
code care if the partly processed request disappears from a queue?
No, it doesn't, and I should have said so. I'll eventually get either
an interrupt or a timer, and in either case it's OK if there's nothing
in the queue.
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.