Re: Miniport's IOCTL interface performance issue.

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

Sounds like "software interrupt coalescing" to me.

Yep, batching TX/Rx can help throughput. I see in NDIStest environment, if
upper layer was sending a lot of net buffers per net buffer list, my driver
can saturate the Gbe link with less than 10% CPU.

OP, note that aggressive interrupt coalescing can hurt latency. I guess this
is the #1 trick in net driver design and tuning. It is the area where
innovation goes.

good luck,
Calvin
--
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

"Stephan Wolf [MVP]" <stewo68@xxxxxxxxxxx> wrote in message
news:1129116713.752256.76060@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> In general, people tend to more and more request performance
> improvements from "the system" rather than revising the design of their
> software.
>
> I guess the answer is no, you cannot expect faster IOCTLs.
>
> A similar problem arose years ago when the number of packets per second
> on the wire grew by a factor of ten (Gigabit Ethernet vs. Fast
> Ethernet). Since we just cannot burden the system with one interrupt
> per packet, what we did was introduce a mechanism known as "interrupt
> moderation", which simply bundles several packets to be handled in just
> one interrupt.
>
> So you could pass more than one packet in a single IOCTL, both send and
> receive.
>
> If a packet is received, do not immediately complete an outstanding IRP
> for it. Instead, start a timer. If either more than a certain number of
> packets has been received *or* the timer expires, whichever comes
> first, complete the IRP.
>
> On the send side (application), similarly gather several send packets
> before passing them down to the driver in a single IRP.
>
> HTH, Stephan
> ---
> Amos wrote:
>> Hi all,
>> I have written a NDIS 5.0 virtual miniport driver that send and receive
>> packets from a usermode application via Direct IOCTL interface. All
>> seems to be working well, except that the miniport drops packets if it
>> receives more that about 3000/second. I have implemented a receive
>> buffer in the miniport and it is clear that the miniport receive all
>> the packets from the above protocols and queue them accordingly but the
>> IOCTL interface seems to be to slow to handle all of the packets, so
>> the queue overflows. Is there any way to improve the IOCTL
>> interface's performance?
>>
>> Thanks,
>> Amos
>


.

Relevant Pages

  • Re: wireless card driver problem about the "done" bit in the descriptor && the bail caused b
    ... And i found that after receiving about 20 packets, ... or a "rxdp bail", the whileloop break, while no interrupt to make ... it off and do a jobQueuePostto wake up tNet0. ... can usually see which descriptors need processing by testing a status ...
    (comp.os.vxworks)
  • Re: wireless card driver problem about the "done" bit in the descriptor && the bail caused b
    ... the VxWorks, ... And i found that after receiving about 20 packets, ... or a "rxdp bail", the whileloop break, while no interrupt to make ... it off and do a jobQueuePostto wake up tNet0. ...
    (comp.os.vxworks)
  • Re: bge dropping packets issue
    ... interrupt driven network I/O? ... Even the Linux driver uses higher number of RX descriptors than ... per second -- missed polls are more likely at higher frequencies. ... talking 100MBps the firmware is dropping packets). ...
    (freebsd-net)
  • Re: bge dropping packets issue
    ... But why was it added to begin with if standard interrupt driven I/O is ... than 150 usec), so 512 descriptors is more than enough for 1Gbps ethernet ... (the minimum possible inter-descriptor time for tiny packets is about 0.6 ... PREEMPTION so that lower-priority interrupt handlers like ata and sc get ...
    (freebsd-net)
  • Re: xl(4) & polling
    ... packet arrived at a network interface, the NIC generated an interrupt. ... Thus the concept of Device Polling came ... Instead whenever the packets arrive at a Network interface, ... the queue may fill up and subsequent packets are dropped. ...
    (freebsd-stable)