I don’t really know if this issue was discussed earlier. It it has, please
tell me where to look.
I have a device used as a grabber in network applications. For the time
being, packets are stored in hard-disk using I/O access. I do not use any
DMA mechanisms between the driver and the device to get the data. This sheme
is very slow. I want to accelerate the procedures.
My questions:
- Suppose I have retrieved a buffer from the device. This buffer is
written (binary) to hard-disk. Is this action (write) envolves any DMA
mechanisms? I think it does due to the ntfs driver.
- Can I write to hard-disk directly from my device? My device has an
MPC860 PowerPC.
I really don’t get the architecture correct. Please, any advice will be
useful.
No you cannot operate the hard disk from your device. The best you can do is to allocate some memory, run your device’s DMA to transfer the data from the device to this memory, then run IDE controller’s DMA to transfer from this memory to the disk.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Nikolas Stylianides
To: Windows System Software Devs Interest List
Sent: Tuesday, April 05, 2005 5:33 PM
Subject: [ntdev] DMA device-hdd
I don’t really know if this issue was discussed earlier. It it has, please tell me where to look.
I have a device used as a grabber in network applications. For the time being, packets are stored in hard-disk using I/O access. I do not use any DMA mechanisms between the driver and the device to get the data. This sheme is very slow. I want to accelerate the procedures.
My questions:
1… Suppose I have retrieved a buffer from the device. This buffer is written (binary) to hard-disk. Is this action (write) envolves any DMA mechanisms? I think it does due to the ntfs driver.
2… Can I write to hard-disk directly from my device? My device has an MPC860 PowerPC.
I really don’t get the architecture correct. Please, any advice will be useful.
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
Nikolas Stylianides wrote:
My questions:
- Suppose I have retrieved a buffer from the device. This buffer is
written (binary) to hard-disk. Is this action (write) envolves any
DMA mechanisms? I think it does due to the ntfs driver.
- Can I write to hard-disk directly from my device? My device has an
MPC860 PowerPC.
There are a couple of issues here, all architectural as I think you guessed.
First, your grabber can almost never take over control of the disk
controller. Running the disk controller is typically the responsibility
of the disk driver. For example, how do you know what type of disk
controller is in use on any given system on which your grabber is running?
Second, whether or not DMA is used depends on the capabilities of the
disk controller. NTFS is the FILE SYSTEM driver, and it supports the
NTFS file system on many different types of disks: Some of which are DMA
and some of which are PIO.
If you want the fastest-path through the system to record grabbed
frames, your best two options are:
a) Writing data to a dedicated, unformatted, disk drive by creating IRPs
that specify the disk offset at which to start writing and the number of
bytes to write, and sending those IRPs directly to the disk driver via
IoCallDriver. Note that whatever offset you specify needs to be sector
aligned. Just to emphasize, this works only when you can “own” the
entire disk. No file system involved.
b) Opening a file on some disk on the system, via the file system
(preferably ntfs) and writing to that file with no intermediate
buffering (i.e. uncached writes). In this case, you open the file in
your grabber driver using ZwCreateFile(…), specifying no intermediate
buffering, and do your writes either by creating write IRPs and sending
them via IoCallDriver or by calling ZwWriteFile(…).
In BOTH cases, note that the write operations *should* take place at
IRQL PASSIVE_LEVEL. You might be able to get by with the write
operations in option A being at IRQL DISPATCH_LEVEL, but this isn’t
really guaranteed.
I hope that helps,
Peter
OSR