The basic approach for queuing multiple concurrent IRPs is:
In DeviceIoControl (assuming CreateFile setup for async I/O):
1.) Map IRP data to system address space, if necessary.
2.) Set cancel routine.
3.) Mark the IRP as pending.
4.) Queue the IRP in a spinlock-protected list, probably using the IRP
Tail.Overlay.ListEntry field for the list pointer(s).
5.) Return STATUS_PENDING.
When buffer (IRP) is needed by driver.
1.) Fetch IRP from queue. CONTAINING_RECORD MACRO is your friend.
2.) Set cancel routine to NULL.
3.) Do work with IRP’s buffer.
4.) Complete the IRP, making sure that IoStatus.Information and
IoStatus.Status are set correctly.
You will also have to handle cancel routine, cleanup, etc.
Suggest that you get a book that describes this sort of function in mode
detail. There are details that you should attend to.
As for the merits of using multiple queued operations instead of large
shared memory buffer: It depends mostly on the anticipated frequency of
user/kernel transitions.
Windows is not a real-time OS and has unpredictable (and sometimes large)
kernel/user latency. If individual operations are performed at high
frequency (e.g., one buffer per network packet), then you will probably
loose packets when using smaller individual I/O operations. In this case,
minimizing kernel/user transition rate (i.e., by using larger shared memory)
will lead to better performance. The amount of data being transferred has a
much smaller performance effect then the frequency of the transfers.
PCAUSA’s Rawether network product has NDIS protocol drivers that uses both
techniques. Using larger buffers provides a definite performance improvement
on higher-speed networks.
(I realize that your application may have nothing to do with networks.
That’s simply where my experience is form.)
Hope this helps.
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client/Filter
http: - http:
wrote in message news:xxxxx@ntdev…
>
> Hi,
>
> I’m looking for some sample code on how to handle multiple
> DeviceIOControls to a driver from user mode.
> I am planning to use overlapped io with multiple events .
>
> In absence of any sample code are there any commments/advice
> on useing such a method. Any potential gotcha’s.
>
> The user mode application would have a number of buffers open with the
> driver which would fill in the buffers with data as recieved and
> complete the IO.
>
> Any advantages/disadvantages to using this method over trying to define
> a large shared memory buffer between the user mode and kernal mode and
> passing the data that way.
>
> Thanks in advance,
> Sunil
>
></http:></http:>