Communication between user-mode and kernel-mode

NTDEV
1

Hi,

I’m currently in the process of making a (virtual) network adapter which,
whenever packets are transmitted on the adapter, forward them to a user-mode
application.

I’m having a hard time deciding how to do notify the user-mode application
about the new data.
One way would be to have the application wait for a read event that gets
signalled by the driver whenever data is received.
Another way could be to let the application read the data using overlapped
I/O and then continually poll the status of the read request until it is
completed by the driver.

What would you guys suggest?

Thanks!

2

Allocate a buffer inside your kernel component (better - ring of buffers
each protected with own spin lock). And signal
shared between user and kernel mode components event so your user mode app
would call DeviceIoControl to grab
the data from kernel driver.

I’d recommend you to grab a copy of NT Insider (sorry, do not remember the
number). There was an article
about how to share named event between user and kernel mode.

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Saturday, January 07, 2006 5:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Communication between user-mode and kernel-mode

Hi,

I’m currently in the process of making a (virtual) network adapter which,
whenever packets are transmitted on the adapter, forward them to a user-mode
application.

I’m having a hard time deciding how to do notify the user-mode application
about the new data.
One way would be to have the application wait for a read event that gets
signalled by the driver whenever data is received.
Another way could be to let the application read the data using overlapped
I/O and then continually poll the status of the read request until it is
completed by the driver.

What would you guys suggest?

Thanks!

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@voliacable.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

3

Thanks for the quick reply!

So when the user-mode application calls DeviceIoControl, would that transfer
all the packets in the ring buffer or just a single packet?

Sharing the event between the driver and the application shouldn’t be a
problem. There are excellent documents on the WHDC site and there’s an event
sample in the DDK.

–Soren

“Anton A. Kolomyeytsev (RDS)” wrote in message
news:xxxxx@ntdev…
Allocate a buffer inside your kernel component (better - ring of buffers
each protected with own spin lock). And signal
shared between user and kernel mode components event so your user mode app
would call DeviceIoControl to grab
the data from kernel driver.

I’d recommend you to grab a copy of NT Insider (sorry, do not remember the
number). There was an article
about how to share named event between user and kernel mode.

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of SÛren Dreijer
Sent: Saturday, January 07, 2006 5:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Communication between user-mode and kernel-mode

Hi,

I’m currently in the process of making a (virtual) network adapter which,
whenever packets are transmitted on the adapter, forward them to a user-mode
application.

I’m having a hard time deciding how to do notify the user-mode application
about the new data.
One way would be to have the application wait for a read event that gets
signalled by the driver whenever data is received.
Another way could be to let the application read the data using overlapped
I/O and then continually poll the status of the read request until it is
completed by the driver.

What would you guys suggest?

Thanks!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@voliacable.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

4

in user-mode, there would be some threads (use them in a completion port + call GetQueuedCompletionStatus in each thread) which would call DeviceIoControl, and you’ll pend those IRPs in your driver; whenever you’ll need to send something to user-mode, you’ll pick the IRP from your buffer and send back; optimal number of waiting threads is usually determined according to number of CPUs and double if it’s a server edition

event can be shared between user-mode and kernel mode, but it’d not be as fast as pending irps (and because you’re working on a network driver, speed matters)

you can also redirect all network traffic on the local port (it depends what you want to do)…

“S?ren Dreijer” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m currently in the process of making a (virtual) network adapter which,
> whenever packets are transmitted on the adapter, forward them to a user-mode
> application.
>
> I’m having a hard time deciding how to do notify the user-mode application
> about the new data.
> One way would be to have the application wait for a read event that gets
> signalled by the driver whenever data is received.
> Another way could be to let the application read the data using overlapped
> I/O and then continually poll the status of the read request until it is
> completed by the driver.
>
> What would you guys suggest?
>
> Thanks!
>
>
>

5

Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver would just pend those IRPs and complete them whenever a packet has been received?

Or, how about having a thread dedicated to reading packet just block on the ReadFile() call and wait for the driver to complete its read request?

Thanks for the reply!

–S?ren
“Petr Kurtin” wrote in message news:xxxxx@ntdev…
in user-mode, there would be some threads (use them in a completion port + call GetQueuedCompletionStatus in each thread) which would call DeviceIoControl, and you’ll pend those IRPs in your driver; whenever you’ll need to send something to user-mode, you’ll pick the IRP from your buffer and send back; optimal number of waiting threads is usually determined according to number of CPUs and double if it’s a server edition

event can be shared between user-mode and kernel mode, but it’d not be as fast as pending irps (and because you’re working on a network driver, speed matters)

you can also redirect all network traffic on the local port (it depends what you want to do)…

“S?ren Dreijer” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m currently in the process of making a (virtual) network adapter which,
> whenever packets are transmitted on the adapter, forward them to a user-mode
> application.
>
> I’m having a hard time deciding how to do notify the user-mode application
> about the new data.
> One way would be to have the application wait for a read event that gets
> signalled by the driver whenever data is received.
> Another way could be to let the application read the data using overlapped
> I/O and then continually poll the status of the read request until it is
> completed by the driver.
>
> What would you guys suggest?
>
> Thanks!
>
>
>

6

Yes you can an depending on the characteristics, this can be faster than the
waiting on an event. Using overlapped I/O in this manner is one of the
simplest method, and unless you set up some fairly sophisticated shared data
structures it is also one of the fastest.

A few years back I took one of the event, IOCTL and ton of shared buffer
models in a driver and said to heck with this, lets just use inverted call.
The customer was terrified because the complexity was there for speed, well
the new method showed no degradation in performance.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver would
just pend those IRPs and complete them whenever a packet has been received?

Or, how about having a thread dedicated to reading packet just block on the
ReadFile() call and wait for the driver to complete its read request?

Thanks for the reply!

7

So you would suggest using a non-blocking call rather than letting
ReadFile() block? Or isn’t there any real performance difference between the
two?

“Don Burn” wrote in message news:xxxxx@ntdev…
> Yes you can an depending on the characteristics, this can be faster than
the
> waiting on an event. Using overlapped I/O in this manner is one of the
> simplest method, and unless you set up some fairly sophisticated shared
data
> structures it is also one of the fastest.
>
> A few years back I took one of the event, IOCTL and ton of shared buffer
> models in a driver and said to heck with this, lets just use inverted
call.
> The customer was terrified because the complexity was there for speed,
well
> the new method showed no degradation in performance.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver
would
> just pend those IRPs and complete them whenever a packet has been
received?
>
> Or, how about having a thread dedicated to reading packet just block on
the
> ReadFile() call and wait for the driver to complete its read request?
>
> Thanks for the reply!
>
>
>
>

8

With Overlapped I/O you can fire off multiple requests in a row, then have
the thread wait for them in order. This makes it easy to keep a number of
buffers ready in the kernel if you need it. If you do not need multiple
buffers, then the performance should not matter.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> So you would suggest using a non-blocking call rather than letting
> ReadFile() block? Or isn’t there any real performance difference between
> the
> two?
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> Yes you can an depending on the characteristics, this can be faster than
> the
>> waiting on an event. Using overlapped I/O in this manner is one of the
>> simplest method, and unless you set up some fairly sophisticated shared
> data
>> structures it is also one of the fastest.
>>
>> A few years back I took one of the event, IOCTL and ton of shared buffer
>> models in a driver and said to heck with this, lets just use inverted
> call.
>> The customer was terrified because the complexity was there for speed,
> well
>> the new method showed no degradation in performance.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> “Søren Dreijer” wrote in message
>> news:xxxxx@ntdev…
>> Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver
> would
>> just pend those IRPs and complete them whenever a packet has been
> received?
>>
>> Or, how about having a thread dedicated to reading packet just block on
> the
>> ReadFile() call and wait for the driver to complete its read request?
>>
>> Thanks for the reply!
>>
>>
>>
>>
>
>
>

9

I’m not sure I’m following. What’s the point in firing off multiple requests
in a row? Why not just call ReadFile() continually?

I’m still new to drivers, so if you could explain it a bit more it would be
greatly appreciated.

Huge thanks!

“Don Burn” wrote in message news:xxxxx@ntdev…
> With Overlapped I/O you can fire off multiple requests in a row, then have
> the thread wait for them in order. This makes it easy to keep a number of
> buffers ready in the kernel if you need it. If you do not need multiple
> buffers, then the performance should not matter.
>
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> > So you would suggest using a non-blocking call rather than letting
> > ReadFile() block? Or isn’t there any real performance difference between
> > the
> > two?
> >
> > “Don Burn” wrote in message news:xxxxx@ntdev…
> >> Yes you can an depending on the characteristics, this can be faster
than
> > the
> >> waiting on an event. Using overlapped I/O in this manner is one of the
> >> simplest method, and unless you set up some fairly sophisticated shared
> > data
> >> structures it is also one of the fastest.
> >>
> >> A few years back I took one of the event, IOCTL and ton of shared
buffer
> >> models in a driver and said to heck with this, lets just use inverted
> > call.
> >> The customer was terrified because the complexity was there for speed,
> > well
> >> the new method showed no degradation in performance.
> >>
> >>
> >> –
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> Remove StopSpam from the email to reply
> >>
> >>
> >>
> >> “Søren Dreijer” wrote in message
> >> news:xxxxx@ntdev…
> >> Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver
> > would
> >> just pend those IRPs and complete them whenever a packet has been
> > received?
> >>
> >> Or, how about having a thread dedicated to reading packet just block on
> > the
> >> ReadFile() call and wait for the driver to complete its read request?
> >>
> >> Thanks for the reply!
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>

10

If you fire off multiple requests, then there is a queue of buffers
available in your driver. So if an asynchonous event with data occurs you
grab the next buffer and fill. If you only have one buffer, then completing
the IRP means if something comes in to the driver before the application
calls back to the driver, you have to either block the event for later
transmission, or buffer the event using a buffer allocated in the driver to
do this. It can be simpler just to have a bunch of buffers in the driver
from the application.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> I’m not sure I’m following. What’s the point in firing off multiple
> requests
> in a row? Why not just call ReadFile() continually?
>
> I’m still new to drivers, so if you could explain it a bit more it would
> be
> greatly appreciated.
>
> Huge thanks!
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> With Overlapped I/O you can fire off multiple requests in a row, then
>> have
>> the thread wait for them in order. This makes it easy to keep a number
>> of
>> buffers ready in the kernel if you need it. If you do not need multiple
>> buffers, then the performance should not matter.
>>
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>> “Søren Dreijer” wrote in message
>> news:xxxxx@ntdev…
>> > So you would suggest using a non-blocking call rather than letting
>> > ReadFile() block? Or isn’t there any real performance difference
>> > between
>> > the
>> > two?
>> >
>> > “Don Burn” wrote in message news:xxxxx@ntdev…
>> >> Yes you can an depending on the characteristics, this can be faster
> than
>> > the
>> >> waiting on an event. Using overlapped I/O in this manner is one of
>> >> the
>> >> simplest method, and unless you set up some fairly sophisticated
>> >> shared
>> > data
>> >> structures it is also one of the fastest.
>> >>
>> >> A few years back I took one of the event, IOCTL and ton of shared
> buffer
>> >> models in a driver and said to heck with this, lets just use inverted
>> > call.
>> >> The customer was terrified because the complexity was there for speed,
>> > well
>> >> the new method showed no degradation in performance.
>> >>
>> >>
>> >> –
>> >> Don Burn (MVP, Windows DDK)
>> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> >> Remove StopSpam from the email to reply
>> >>
>> >>
>> >>
>> >> “Søren Dreijer” wrote in message
>> >> news:xxxxx@ntdev…
>> >> Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver
>> > would
>> >> just pend those IRPs and complete them whenever a packet has been
>> > received?
>> >>
>> >> Or, how about having a thread dedicated to reading packet just block
>> >> on
>> > the
>> >> ReadFile() call and wait for the driver to complete its read request?
>> >>
>> >> Thanks for the reply!
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>

11

What if you have multiple user-side threads ? That might
generate more than one outstanding irp. Or, say, you need to
load multiple textures before you render, so, you load all those
textures in parallel.

Alberto.

----- Original Message -----
From: “Søren Dreijer”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”

Sent: Saturday, January 07, 2006 12:07 PM
Subject: Re:[ntdev] Communication between user-mode and
kernel-mode

> I’m not sure I’m following. What’s the point in firing off
> multiple requests
> in a row? Why not just call ReadFile() continually?
>
> I’m still new to drivers, so if you could explain it a bit
> more it would be
> greatly appreciated.
>
> Huge thanks!
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> With Overlapped I/O you can fire off multiple requests in a
>> row, then have
>> the thread wait for them in order. This makes it easy to
>> keep a number of
>> buffers ready in the kernel if you need it. If you do not
>> need multiple
>> buffers, then the performance should not matter.
>>
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>> “Søren Dreijer” wrote in message
>> news:xxxxx@ntdev…
>> > So you would suggest using a non-blocking call rather than
>> > letting
>> > ReadFile() block? Or isn’t there any real performance
>> > difference between
>> > the
>> > two?
>> >
>> > “Don Burn” wrote in message
>> > news:xxxxx@ntdev…
>> >> Yes you can an depending on the characteristics, this can
>> >> be faster
> than
>> > the
>> >> waiting on an event. Using overlapped I/O in this manner
>> >> is one of the
>> >> simplest method, and unless you set up some fairly
>> >> sophisticated shared
>> > data
>> >> structures it is also one of the fastest.
>> >>
>> >> A few years back I took one of the event, IOCTL and ton of
>> >> shared
> buffer
>> >> models in a driver and said to heck with this, lets just
>> >> use inverted
>> > call.
>> >> The customer was terrified because the complexity was
>> >> there for speed,
>> > well
>> >> the new method showed no degradation in performance.
>> >>
>> >>
>> >> –
>> >> Don Burn (MVP, Windows DDK)
>> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> >> Remove StopSpam from the email to reply
>> >>
>> >>
>> >>
>> >> “Søren Dreijer” wrote in message
>> >> news:xxxxx@ntdev…
>> >> Couldn’t I just use overlapped I/O with ReadFile()? I
>> >> mean, the driver
>> > would
>> >> just pend those IRPs and complete them whenever a packet
>> >> has been
>> > received?
>> >>
>> >> Or, how about having a thread dedicated to reading packet
>> >> just block on
>> > the
>> >> ReadFile() call and wait for the driver to complete its
>> >> read request?
>> >>
>> >> Thanks for the reply!
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

12

>Couldn’t I just use overlapped I/O with ReadFile()? I mean, the driver would
just

pend those IRPs and complete them whenever a packet has been received?

Yes, this is OK.

Or, how about having a thread dedicated to reading packet just block on the
ReadFile() call and wait for the driver to complete its read request?

Also a good way.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

13

I think you’d like to copy all of the filled buffers from kernel -> user.
Having more then one “shared” buffer protected
with single spin lock would allow your kernel driver keep filling the
buffers with data while user mode app would copy
filled ones to user space.

Well… I’d still recommend you to get THAT article :slight_smile:

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Soren Dreijer
Sent: Saturday, January 07, 2006 6:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Communication between user-mode and kernel-mode

Thanks for the quick reply!

So when the user-mode application calls DeviceIoControl, would that transfer
all the packets in the ring buffer or just a single packet?

Sharing the event between the driver and the application shouldn’t be a
problem. There are excellent documents on the WHDC site and there’s an event
sample in the DDK.

–Soren

“Anton A. Kolomyeytsev (RDS)” wrote in message
news:xxxxx@ntdev…
Allocate a buffer inside your kernel component (better - ring of buffers
each protected with own spin lock). And signal shared between user and
kernel mode components event so your user mode app would call
DeviceIoControl to grab the data from kernel driver.

I’d recommend you to grab a copy of NT Insider (sorry, do not remember the
number). There was an article about how to share named event between user
and kernel mode.

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Saturday, January 07, 2006 5:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Communication between user-mode and kernel-mode

Hi,

I’m currently in the process of making a (virtual) network adapter which,
whenever packets are transmitted on the adapter, forward them to a user-mode
application.

I’m having a hard time deciding how to do notify the user-mode application
about the new data.
One way would be to have the application wait for a read event that gets
signalled by the driver whenever data is received.
Another way could be to let the application read the data using overlapped
I/O and then continually poll the status of the read request until it is
completed by the driver.

What would you guys suggest?

Thanks!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@voliacable.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@voliacable.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

14

If you have multiple pending read/ioctl irps, there is a single copy, from the NIC to the IRP and your are done (assuming there is a pending irp when data arrives, otherwise there are 2 copies, but this is heavily tunable). No more synchronization needed.

If you have a shared event, you have a morec compicated life b/c you must also synchronize the current head ptr into the ring buffer against the data size in the buffer which means another event (which also means you can’t acquire it at dispatch level in the driver when you get data, which means queueing a work item). Also, if you are sharing memory, you now need to manage that mapping when the app exits unexpectedly (otherwise you bugcheck).

In the end, the pure pending irp model is simpler and faster b/c there are fewer (as in none) sync objects being contended for between UM and KM.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Anton A. Kolomyeytsev (RDS)
Sent: Saturday, January 07, 2006 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Communication between user-mode and kernel-mode

I think you’d like to copy all of the filled buffers from kernel -> user.
Having more then one “shared” buffer protected
with single spin lock would allow your kernel driver keep filling the
buffers with data while user mode app would copy
filled ones to user space.

Well… I’d still recommend you to get THAT article :slight_smile:

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Soren Dreijer
Sent: Saturday, January 07, 2006 6:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Communication between user-mode and kernel-mode

Thanks for the quick reply!

So when the user-mode application calls DeviceIoControl, would that transfer
all the packets in the ring buffer or just a single packet?

Sharing the event between the driver and the application shouldn’t be a
problem. There are excellent documents on the WHDC site and there’s an event
sample in the DDK.

–Soren

“Anton A. Kolomyeytsev (RDS)” wrote in message
news:xxxxx@ntdev…
Allocate a buffer inside your kernel component (better - ring of buffers
each protected with own spin lock). And signal shared between user and
kernel mode components event so your user mode app would call
DeviceIoControl to grab the data from kernel driver.

I’d recommend you to grab a copy of NT Insider (sorry, do not remember the
number). There was an article about how to share named event between user
and kernel mode.

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Saturday, January 07, 2006 5:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Communication between user-mode and kernel-mode

Hi,

I’m currently in the process of making a (virtual) network adapter which,
whenever packets are transmitted on the adapter, forward them to a user-mode
application.

I’m having a hard time deciding how to do notify the user-mode application
about the new data.
One way would be to have the application wait for a read event that gets
signalled by the driver whenever data is received.
Another way could be to let the application read the data using overlapped
I/O and then continually poll the status of the read request until it is
completed by the driver.

What would you guys suggest?

Thanks!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@voliacable.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@voliacable.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

15

Ah, ok, makes sense. I was just already considering buffering internally so
I didn’t see the need for multiple requests.

So, in the multiple requests scenario one calls ReadCall() with overlapped
I/O several times in a row with different buffers?

Thank you so much,

“Don Burn” wrote in message news:xxxxx@ntdev…
> If you fire off multiple requests, then there is a queue of buffers
> available in your driver. So if an asynchonous event with data occurs you
> grab the next buffer and fill. If you only have one buffer, then
completing
> the IRP means if something comes in to the driver before the application
> calls back to the driver, you have to either block the event for later
> transmission, or buffer the event using a buffer allocated in the driver
to
> do this. It can be simpler just to have a bunch of buffers in the driver
> from the application.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> > I’m not sure I’m following. What’s the point in firing off multiple
> > requests
> > in a row? Why not just call ReadFile() continually?
> >
> > I’m still new to drivers, so if you could explain it a bit more it would
> > be
> > greatly appreciated.
> >
> > Huge thanks!
> >
> >
> > “Don Burn” wrote in message news:xxxxx@ntdev…
> >> With Overlapped I/O you can fire off multiple requests in a row, then
> >> have
> >> the thread wait for them in order. This makes it easy to keep a number
> >> of
> >> buffers ready in the kernel if you need it. If you do not need
multiple
> >> buffers, then the performance should not matter.
> >>
> >>
> >>
> >> –
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> Remove StopSpam from the email to reply
> >>
> >>
> >> “Søren Dreijer” wrote in message
> >> news:xxxxx@ntdev…
> >> > So you would suggest using a non-blocking call rather than letting
> >> > ReadFile() block? Or isn’t there any real performance difference
> >> > between
> >> > the
> >> > two?
> >> >
> >> > “Don Burn” wrote in message news:xxxxx@ntdev…
> >> >> Yes you can an depending on the characteristics, this can be faster
> > than
> >> > the
> >> >> waiting on an event. Using overlapped I/O in this manner is one of
> >> >> the
> >> >> simplest method, and unless you set up some fairly sophisticated
> >> >> shared
> >> > data
> >> >> structures it is also one of the fastest.
> >> >>
> >> >> A few years back I took one of the event, IOCTL and ton of shared
> > buffer
> >> >> models in a driver and said to heck with this, lets just use
inverted
> >> > call.
> >> >> The customer was terrified because the complexity was there for
speed,
> >> > well
> >> >> the new method showed no degradation in performance.
> >> >>
> >> >>
> >> >> –
> >> >> Don Burn (MVP, Windows DDK)
> >> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> >> Remove StopSpam from the email to reply
> >> >>
> >> >>
> >> >>
> >> >> “Søren Dreijer” wrote in message
> >> >> news:xxxxx@ntdev…
> >> >> Couldn’t I just use overlapped I/O with ReadFile()? I mean, the
driver
> >> > would
> >> >> just pend those IRPs and complete them whenever a packet has been
> >> > received?
> >> >>
> >> >> Or, how about having a thread dedicated to reading packet just block
> >> >> on
> >> > the
> >> >> ReadFile() call and wait for the driver to complete its read
request?
> >> >>
> >> >> Thanks for the reply!
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>
>
>

16

Yeah, that would indeed generate more than one outstanding IRP. Though, in
my particular case I would only read from one single thread. That isn’t
perfect, of course, as I would encounter problems at a later time if I
decided to change the number of threads reading data from the driver.

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> What if you have multiple user-side threads ? That might
> generate more than one outstanding irp. Or, say, you need to
> load multiple textures before you render, so, you load all those
> textures in parallel.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Søren Dreijer”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, January 07, 2006 12:07 PM
> Subject: Re:[ntdev] Communication between user-mode and
> kernel-mode
>
>
> > I’m not sure I’m following. What’s the point in firing off
> > multiple requests
> > in a row? Why not just call ReadFile() continually?
> >
> > I’m still new to drivers, so if you could explain it a bit
> > more it would be
> > greatly appreciated.
> >
> > Huge thanks!
> >
> >
> > “Don Burn” wrote in message news:xxxxx@ntdev…
> >> With Overlapped I/O you can fire off multiple requests in a
> >> row, then have
> >> the thread wait for them in order. This makes it easy to
> >> keep a number of
> >> buffers ready in the kernel if you need it. If you do not
> >> need multiple
> >> buffers, then the performance should not matter.
> >>
> >>
> >>
> >> –
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> Remove StopSpam from the email to reply
> >>
> >>
> >> “Søren Dreijer” wrote in message
> >> news:xxxxx@ntdev…
> >> > So you would suggest using a non-blocking call rather than
> >> > letting
> >> > ReadFile() block? Or isn’t there any real performance
> >> > difference between
> >> > the
> >> > two?
> >> >
> >> > “Don Burn” wrote in message
> >> > news:xxxxx@ntdev…
> >> >> Yes you can an depending on the characteristics, this can
> >> >> be faster
> > than
> >> > the
> >> >> waiting on an event. Using overlapped I/O in this manner
> >> >> is one of the
> >> >> simplest method, and unless you set up some fairly
> >> >> sophisticated shared
> >> > data
> >> >> structures it is also one of the fastest.
> >> >>
> >> >> A few years back I took one of the event, IOCTL and ton of
> >> >> shared
> > buffer
> >> >> models in a driver and said to heck with this, lets just
> >> >> use inverted
> >> > call.
> >> >> The customer was terrified because the complexity was
> >> >> there for speed,
> >> > well
> >> >> the new method showed no degradation in performance.
> >> >>
> >> >>
> >> >> –
> >> >> Don Burn (MVP, Windows DDK)
> >> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> >> Remove StopSpam from the email to reply
> >> >>
> >> >>
> >> >>
> >> >> “Søren Dreijer” wrote in message
> >> >> news:xxxxx@ntdev…
> >> >> Couldn’t I just use overlapped I/O with ReadFile()? I
> >> >> mean, the driver
> >> > would
> >> >> just pend those IRPs and complete them whenever a packet
> >> >> has been
> >> > received?
> >> >>
> >> >> Or, how about having a thread dedicated to reading packet
> >> >> just block on
> >> > the
> >> >> ReadFile() call and wait for the driver to complete its
> >> >> read request?
> >> >>
> >> >> Thanks for the reply!
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
>

17

Oh, and might I add, wouldn’t you need an internal buffering mechanism
anyway, in case you run out of request buffers?

–Soren

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Ah, ok, makes sense. I was just already considering buffering internally
so
> I didn’t see the need for multiple requests.
>
> So, in the multiple requests scenario one calls ReadCall() with overlapped
> I/O several times in a row with different buffers?
>
> Thank you so much,
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
> > If you fire off multiple requests, then there is a queue of buffers
> > available in your driver. So if an asynchonous event with data occurs
you
> > grab the next buffer and fill. If you only have one buffer, then
> completing
> > the IRP means if something comes in to the driver before the application
> > calls back to the driver, you have to either block the event for later
> > transmission, or buffer the event using a buffer allocated in the driver
> to
> > do this. It can be simpler just to have a bunch of buffers in the
driver
> > from the application.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Søren Dreijer” wrote in message
news:xxxxx@ntdev…
> > > I’m not sure I’m following. What’s the point in firing off multiple
> > > requests
> > > in a row? Why not just call ReadFile() continually?
> > >
> > > I’m still new to drivers, so if you could explain it a bit more it
would
> > > be
> > > greatly appreciated.
> > >
> > > Huge thanks!
> > >
> > >
> > > “Don Burn” wrote in message news:xxxxx@ntdev…
> > >> With Overlapped I/O you can fire off multiple requests in a row, then
> > >> have
> > >> the thread wait for them in order. This makes it easy to keep a
number
> > >> of
> > >> buffers ready in the kernel if you need it. If you do not need
> multiple
> > >> buffers, then the performance should not matter.
> > >>
> > >>
> > >>
> > >> –
> > >> Don Burn (MVP, Windows DDK)
> > >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >> Remove StopSpam from the email to reply
> > >>
> > >>
> > >> “Søren Dreijer” wrote in message
> > >> news:xxxxx@ntdev…
> > >> > So you would suggest using a non-blocking call rather than letting
> > >> > ReadFile() block? Or isn’t there any real performance difference
> > >> > between
> > >> > the
> > >> > two?
> > >> >
> > >> > “Don Burn” wrote in message news:xxxxx@ntdev…
> > >> >> Yes you can an depending on the characteristics, this can be
faster
> > > than
> > >> > the
> > >> >> waiting on an event. Using overlapped I/O in this manner is one
of
> > >> >> the
> > >> >> simplest method, and unless you set up some fairly sophisticated
> > >> >> shared
> > >> > data
> > >> >> structures it is also one of the fastest.
> > >> >>
> > >> >> A few years back I took one of the event, IOCTL and ton of shared
> > > buffer
> > >> >> models in a driver and said to heck with this, lets just use
> inverted
> > >> > call.
> > >> >> The customer was terrified because the complexity was there for
> speed,
> > >> > well
> > >> >> the new method showed no degradation in performance.
> > >> >>
> > >> >>
> > >> >> –
> > >> >> Don Burn (MVP, Windows DDK)
> > >> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >> >> Remove StopSpam from the email to reply
> > >> >>
> > >> >>
> > >> >>
> > >> >> “Søren Dreijer” wrote in message
> > >> >> news:xxxxx@ntdev…
> > >> >> Couldn’t I just use overlapped I/O with ReadFile()? I mean, the
> driver
> > >> > would
> > >> >> just pend those IRPs and complete them whenever a packet has been
> > >> > received?
> > >> >>
> > >> >> Or, how about having a thread dedicated to reading packet just
block
> > >> >> on
> > >> > the
> > >> >> ReadFile() call and wait for the driver to complete its read
> request?
> > >> >>
> > >> >> Thanks for the reply!
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>

18

It depends on how well your application and driver are coordinated. For
instance if you took the slowest system you had, made overlapped I/O count
large, and then drove the device as fast as possible you could with a little
instrunentation find out what was the largest number of buffers in use by
the application. Double that amount and you would be safe. It really
depends on the application, the device and the level of reliability you
want.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Oh, and might I add, wouldn’t you need an internal buffering mechanism
> anyway, in case you run out of request buffers?
>
> --Soren
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
>> Ah, ok, makes sense. I was just already considering buffering internally
> so
>> I didn’t see the need for multiple requests.
>>
>> So, in the multiple requests scenario one calls ReadCall() with
>> overlapped
>> I/O several times in a row with different buffers?
>>
>> Thank you so much,

19

Yeah, sounds like a good idea. For the practice (I’m still fairly new to
driver development), I might be implementing both internal buffering as well
as multiple requests.

Thank you so much for your time.

“Don Burn” wrote in message news:xxxxx@ntdev…
> It depends on how well your application and driver are coordinated. For
> instance if you took the slowest system you had, made overlapped I/O count
> large, and then drove the device as fast as possible you could with a
little
> instrunentation find out what was the largest number of buffers in use by
> the application. Double that amount and you would be safe. It really
> depends on the application, the device and the level of reliability you
> want.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> > Oh, and might I add, wouldn’t you need an internal buffering mechanism
> > anyway, in case you run out of request buffers?
> >
> > --Soren
> >
> > “Søren Dreijer” wrote in message
news:xxxxx@ntdev…
> >> Ah, ok, makes sense. I was just already considering buffering
internally
> > so
> >> I didn’t see the need for multiple requests.
> >>
> >> So, in the multiple requests scenario one calls ReadCall() with
> >> overlapped
> >> I/O several times in a row with different buffers?
> >>
> >> Thank you so much,
>
>
>