Output is easier to manage than input.
Nothing fancy is required, certainly not something of this complexity.
Using WriteFile or DeviceIoControl, use Direct I/O mode. Upon completion of
the IRP, start the next packet from the queue of pending IRPs and complete
the current IRP.
Note that starting the next IRP from the queue is a very fast operation,
probably, realistically, < 10us.
Pre-queue a bunch of messages. Note that the space required for buffers is
no greater than the space required by your proposed solution (in fact, you
can arrange it so that you don’t use any more space in either design).
You are hung up on the notion that the application has to process an
interrupt. This is a completely bogus line of reasoning. The application
doesn’t even CARE about the concept of interrupt, nor should it.
A simple FIFO design (no more complex than the old
IoStartPacket/IoStartNextPacket model) is sufficient, but you would want to
use KMDF and cancel-safe queues, but the base complexity is about an order
of magnitude smaller than the idea you are proposing. Small and simple
beats baroque and grotesque every time.
The app still has to generate data fast enough, but the simple FIFO queue
model does it in a manner consistent with the philosophy of Windows I/O, and
the solutions of using a large buffer as you describe result in NO
performance improvement in user-space/kernel-space interaction, and just
create a bizarre structure that will be hard to program and maintain.
Keep the solution simple.
As I already pointed out, the buffer will be locked down (in either case) so
the memory will never be “allocated [on] disk”, that is, paged out. The
total buffer consumption is essentially identical in your model and the
simple FIFO queue model.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Saturday, December 20, 2008 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DMA from virtual memory to hardware
xxxxx@elta.co.il wrote:
My PCI hardware creates interrupt every ~10ms. Upon interrupt the
application has to write a buffer to the hardware using the device driver.
I thought to allocate a virtual continuous buffer in application and to
send its address to the driver using IOCTL request.
Upon interrupt the driver will start a DMA from this address to the
hardware. Upon completion the application and driver will advance the
address by a predefined number.
The assumption is that there will always be a new buffer written before an
interrupt arrives.
This way the application will not have to handle each interrupt.
But if the virtual memory will be allocated in disk (not in RAM) ? will
DMA work ?
Is this a wise strategy ?
A wise strategy for an electronic engineer is to find somebody
software-minded to do the driver.
“It’s better together” (c)
Or… take a course.
Interaction between driver and app is better done with a queue of pending
requests - as in many replies you’ve already received.
The driver completes the request when it’s data is transferred, the app
recycles the request.
It’s possible to get away with one common cyclic buffer - in the sense that
nothing is impossible. But why, when there’s a simpler and safer way.
The term “common” or “shared” buffer in WDK means locked, non-pageable,
often non-cached kernel memory shared between the PC and the DMA master
(your PCIe card).
This does not mean that the sharing should occur also between kernel and
user mode.
Have a good week, and Seasonal Greetings, --PA
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
