Re: WDFQUEUE's REQUIRE DISPATCH_LEVEL operation on X64/AMD64 platf
- From: "Doron Holan [MSFT]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 16 Jun 2008 13:40:14 -0700
there is no difference in the KMDF code for WDFIOQUEUE for x32 and x64, it is all exactly the same. perhaps some of the coding patterns have different perf implications between the 2, but the framework does not have any special code between these platforms.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"RayU" <rayu@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:62D94602-9C7A-434F-843E-BC30CBA9738E@xxxxxxxxxxxxxxxx
The thread issuing IOCTL's to the driver is operating @ an elevated priority
of "RealTime". Our application using the driver, on our system, is designed
to make sure it produces video/audio updates as playouts and/or ingests at a
standard rate of ~16.m.s per frame (NTSC). It might be one port or six (max
6 ports @ ~16 m.s.). However the actual CPU utilized by the playout/ingest
is essentially negligable, even if all six ports are in operation
simultaneously. The elevated thread priority design is simply to make sure a
video/audio update is "not missed" when the system is heavily loaded for what
ever reason. Therefore the issue is simply that the combination of the
KMDF/WDFQUEUE requires a pre-processed Irp simply to raise the execution
level to DISPATCH level prior to insertion into the KMDF framework in order
to handle our requirement of not missing video/audio updates. If I build the
driver for XP on the same hardware platform the WDFQUEUE handles this
condition in the maner I would expect. As long as the our controlling thread
has an elevated priority, no video/audio updates are missed, competely
manually synchronized. If I do not raise the execution level prior to
insertion into the framework with the amd64 build, then it basically might
update approxiametely every forth frame (4 CPU system), it's almost like the
elevated thread priority is not being recongnized by the frameworks queue
with the amd64 build, which is our IOCTL entry point for the driver. A KMDF
driver which functions exactly as we expect on XP, requires this strange
configuration in order to function correctly on XPx64/amd64 (all IOCTL's must
execute @ DISPATCH_LEVEL under 100% CPU load). This IO thread is one of many
processes in our application environment. Thus ideally we would prefer the
driver operate @ PASSIVE_LEVEL when possible, like it does with the XP build.
Thus in order to meet our requirements I have already begun porting it to
the WDM.
"Doron Holan [MSFT]" wrote:
it is a bit unclear to me why you need to configure the queues differently
on x64. is it b/c you are not getting the bandwidth you expect or see on 32
bit? Please restate your problem statement (and not what you did to work
around that problem).
thx
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"RayU" <rayu@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D3C510D9-D2A8-4BD0-9EEF-5EC8F7572F17@xxxxxxxxxxxxxxxx
> 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 ?
.
- Follow-Ups:
- References:
- Re: WDFQUEUE's REQUIRE DISPATCH_LEVEL operation on X64/AMD64 platform
- From: Doron Holan [MSFT]
- Re: WDFQUEUE's REQUIRE DISPATCH_LEVEL operation on X64/AMD64 platf
- From: RayU
- Re: WDFQUEUE's REQUIRE DISPATCH_LEVEL operation on X64/AMD64 platform
- Prev by Date: Re: general purpose driver for Printer Port?
- Next by Date: Re: WM_DEVICECHANGE PARAMETERS
- Previous by thread: Re: WDFQUEUE's REQUIRE DISPATCH_LEVEL operation on X64/AMD64 platf
- Next by thread: Re: WDFQUEUE's REQUIRE DISPATCH_LEVEL operation on X64/AMD64 platf
- Index(es):
Relevant Pages
|
