Circular Buffers.

NTDEV
1

Hi Everyone,

I was wondering if anyone know of any good examples of passing data from a
device driver to a application. The data is in the form of points.

My biggest fear is that the device driver may put information into the
buffer too quickly and the application will fail. . . If it does any
thoughts on what to do?

Joe McCloskey
Gamry Instruments

2

You can look at the mouclass and kbdclass examples in the XP DDK. Both
of them maintain a ring buffer of data that the reads. For example in
kbdclass, look at KeyboardClassServiceCallback for the insertion of data
and KeyboardClassRead for the removal of data or queueing of the IRP.

d

-----Original Message-----
From: xxxxx@gamry.com [mailto:xxxxx@gamry.com]
Sent: Friday, April 05, 2002 11:34 AM
To: NT Developers Interest List
Subject: [ntdev] Circular Buffers.

Hi Everyone,

I was wondering if anyone know of any good examples of passing data from
a
device driver to a application. The data is in the form of points.

My biggest fear is that the device driver may put information into the
buffer too quickly and the application will fail. . . If it does any
thoughts on what to do?

Joe McCloskey
Gamry Instruments

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

3

wrote in message news:xxxxx@ntdev…
>
> My biggest fear is that the device driver may put information into the
> buffer too quickly and the application will fail.
>

This is usually one reason for using IOCTLs to pass the data between the app
and the driver. It’s an “automatic” sort of way for the app to throttle the
return of the data. The way this usually works is that the driver
internally buffers the data, and returns it in response to IOCTLs from the
user app.

Assuming you hate this idea, and want to return the data directly (into a
mapped hunk of memory, shared by the driver and app), other ways of doing
this are coordination using head/tail pointers. The app updates the head
pointer (and reads the tail pointer) and the driver updates the tail pointer
(and reads the head pointer). If the head reaches the tail, the app’s
caught up. If the tail reaches the head, the circular buffer is full and
the driver needs to stall. This is most easily done with fixed length
entries (though there’s no requirement that this be the case), and you often
see it done such that at least one free entry always exists between the head
and tail – This isn’t strictly required but helps chill people’s paranoia
about such schemes (and makes reading the pointers a bit easier).

Peter
OSR

4

If each data item is large, and you can predict the size, then using overlapped
I/O, with an IRP per request, is a reasonable idea. The packet driver
sample does this. There is nothing particularly wrong with a 100 outstanding
requests.

If the data items are small or variable length (e.g., as in the packet driver sample),
then the overhead per IRP can kill you.

If the application expects a byte stream with variable sizes arriving, an algorithm I used was the following:

  • the application issues n reads
  • the driver remembers the maximum number of reads its ever had outstanding at once as m
  • when data arrives, appending it to the buffer associated with the oldest IRP.
  • If the buffer fills, or m read IRPs are outstanding, complete the IRP
  • otherwise, hold onto the IRP.
  • If you get a read IRP which causes your count to got to m, then complete any partially filled IRP, if any.
  • Also complete partially filled IRPs on realtively long timer expriation to avoid hanging an uncooperative application.

The above gives you good response time for single events, but reduces the overhead on heavy load.

If you are getting message/packets, then you can do a similar thing using IOCTLs, or you can
hack of the bytestream to describe message boundaries.

When I did something like this to the packet driver, I was able to receive 3-4 times as many
packets before it would drop packets as with the standard driver with 500 IRPs.

-DH

PS. A shared user/kernel circular buffer is also feasible, but generally unnecessary.

wrote in message news:xxxxx@ntdev…
>
> Hi Everyone,
>
> I was wondering if anyone know of any good examples of passing data from a
> device driver to a application. The data is in the form of points.
>
> My biggest fear is that the device driver may put information into the
> buffer too quickly and the application will fail. . . If it does any
> thoughts on what to do?
>
> Joe McCloskey
> Gamry Instruments
>
>