We started with an WDM/DriverWorks driver for a DMA based Media IO device on
an XP/amd64 platform. We ported the driver to KMDF in order to remove our
dependence on DriverWorks tools. The KMDF framework functions as we expect
from the documentation. When our process which issues IOCTL's to the driver
is executing @ a RealTime priority the Media buffers continue to be updated
(rate~16m.s. X #Channels) periodically by the device even when the CPU is
loaded to 100%, due to our elevated priority controlling thread. The KMDF
framework entry is @ PASSIVE_LEVEL, the attributes of the queue are
configured as WdfSynchronizationScopeNone, WdfIoQueueDispatchParallel. KMDF
SPIN_LOCKS are used to protect HW registers and to serilalize a particular
DMA channel. Requests are forwarded via WdfRequestForwardToIoQueue to a
manual queue for each channel and a DPC grabs the next request. Same basic
design model as our previous driver which handles this condition fine on
XPx64/amd64. Next we started testing on XPx64/amd64. Now the exact same
code REQUIRE'S the queue be configured via WdfSynchronizationScopeQueue, and
the Irp routed via a framework method
WdfDeviceInitAssignWdmIrpPreprocessCallback where the execution level is
elevated prior to insertion into the framework via
WdfDeviceWdmDispatchPreprocessedIrp. Basically, I believe the WDFQUEUE,
default queue, or if configured via WdfDeviceConfigureRequestDispatching (
WdfRequestTypeDeviceControl), only operates from our perspective correctly if
the execution level is DISPATCH_LEVEL on XPx64/amd64. So I quess you might
say it works, great. However our product environment is extremely CPU
intensive with many processess utilizing the CPU. Thus ideally we would like
to be executing @ PASSIVE_LEVEL whenever possible in our driver to allow the
scheduler to optimize CPU utilization rather than having the driver be
selfish. Soon I am going to setup one of our IA64 systems with XPx64 and
build the driver for that environment, I am wondering if this is not a issue
on that platform. After all its native ( WARNING: X64 NATIVE compiling
isn't supported. Using cross compilers ). The WDM/DriverWorks version is
build with the Windows Server 2003 DDK. The KMDF version is build with the
Server 2008 WDK using KMDF 1.7. Finally, my question is, should I build this
driver using WDM exclusively because I am positive this would remove the
DISPATCH_LEVEL entry requirement ! thus allowing our products to optimize the
multiprocessor system as much as possible ? Or should I put some effort into
the IA64 platform and prove this is a WDFQUEUE issue and hope someday soon
they will resolve my issue because most of our products ship on XPx64/amd64
mutliprocessor systems ? Of course the other possibility is that I am doing
something incorrectly. However why would this design function exactly as
expected on XP and not XPx64 ? Furthermore, I have exhausted, in my opinion,
all possible methods to insert the IOCTL based request into the framework and
have the buffers update periodically when the CPU is loaded to 100% without a
bump in the execution level, with no success. Even created a complely manual
based model and raised the execution level within the framework at all times,
and it did not handle this condition. It really appears as if the something
strange/different is happening on enrty into the framework on XPx64/amd64.
Does anybody have a recommendatiion ?
3C510D9-D2A8-4BD0-9EEF-5EC8F7572F17@microsoft.com...