Re: How queue APC from kernel?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Don Burn (burn_at_stopspam.acm.org)
Date: 12/22/04 

Date: Wed, 22 Dec 2004 13:33:58 -0500

Hannes,

     I've done this type of architecture with a queue and a semaphore. You
have a common control block you queue using ExInterlockedXXX queue routine
and increment the semphore, the main thread waits on the semaphore and
dequeues an item to process. You probably should have a lookaside list for
allocating the control blocks.

     The kernel actually has a kernel queue that does the instertion and
notification, unfortunately it is only documented in the IFS kit. 

-- 
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
"Hannes" <hannes@nospam.nospam> wrote in message
news:130329E4-515D-4B5A-950A-569AD0E24B4D@microsoft.com...
> The exact problem I'm having is; I'm writing a driver which will service a
> 4-port serial card (among many other tasks). I am communicating with the
> vendor supplied card driver, which will invoke different callback
functions
> in my driver, depending on which serial port needs service.
>
> My callback function(s) will not carry out the actual send/receive
> operations, I rather want to execute these on a main thread in my driver.
My
> idea is that the callback function(s) should queue some APC to be executed
by
> my main thread, and I would store the port to be serviced, along with the
> operation required (e.g. rx or tx) inside the APC to be executed.
>
> Just setting an event to wake up my main thread is not enough, since the
> event can't carry any data to indicate port number and/or desired
operation.
> Also, I can't use mulitple events, since a kernel thread only can wait for
a
> maximum of 3 events.
>
> We're using a similar method in a user space application, so that's why
I'm
> fairly familiar with QueueUserAPC in user space. Would therefore like to
make
> a similar approach in kernel space.
>
> - Am I missing something? Is there a better approach?
> - Will DPC's be able to do this for me? (as oppose to APC's)
>
> Thanks,
>
>               / Hannes.

Relevant Pages

  • [RFC] macvlan: add tap device backend
    ... This is a second prototype of a new interface into the network ... to eventually replace tun/tap and the bridge driver ... we can do most of that efficiently in the Linux bridge code, ... * A macvtap queue is the central object of this driver, ...
    (Linux-Kernel)
  • Re: Latency issues with buf_ring
    ... been to make a compile option to the driver, but a REAL fix would be much ... result in really high packet latencies in some cases. ... The race, of course, is that the thread holding the lock ... for that queue. ...
    (freebsd-net)
  • Re: IF_HANDOFF vs. IFQ_HANDOFF
    ... Is IF_HANDOFF supposed to be used only when the target queue is not the ... The network adapter's transmit descriptor ring ... whether coalescing that locking with existing driver locking makes ... The whole point of the IFF_OACTIVE flag is to suppress the call to the ...
    (freebsd-net)
  • Re: Changes in the network interface queueing handoff model
    ... layer output routine via ifp->if_outputwith the ifnet pointer, packet, ... as ARP), and hands off to the ifnet driver via a call to IFQ_HANDOFF, ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)
  • Changes in the network interface queueing handoff model
    ... 5BOne of the ideas that I, Scott Long, and a few others have been bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)