Message 5 of 5
15 May 17 20:19
Join Date: 21 Oct 2010
Posts To This List: 737
Observing low RX throughput for 10G ethernet NIC
This topic is too large for a discussion on a form like this, but briefly
consider the following:
If the volume of packets arriving at your NIC is very low, then there will be a
long time between received packets. During the interval between packets, it
would be wasteful for a CPU to be continually polling your device for new data
that does not exist, so the OS should go ahead and schedule other activities and
when a packet has arrived and the device needs attention it should trigger an
interrupt. This will allow the OS to schedule threads and efficiently use CPU
resources while still giving your device the attention that it needs when there
is actually something to do.
If the volume of packets arriving at your NIC is very high, then there will be
no time at all between received packets. The packets will be read off of the
wire and become available for consumption by the OS faster than any single CPU
could handle them. In this situation, using an interrupt would be wasteful
because it requires a context switch that will consume CPU resources that could
otherwise be used to retrieve or process packets. In this situation a long
running DPC that continually provides upper layers in the OS new packets to
process would allow a machine with a sufficient number of cores to achieve a
higher throughput. Your device requires continuous attention and it gets it. A
refinement that further increases throughput is to pre-classify the packets on
your device into the probable network streams so that each ?connection? can be
handled in a separate instance of the DPC function that can run concurrently (a
facet of RSS).
The key problem is knowing when to use each mode and how to limit the
monopolization of system resources when in polling mode. This will be device
and system specific, but well designed algorithms can handle this.
This is not to mention the myriad of hardware offload and other optimizations
that are supported in the modern stack. These add significant complications to
the tradeoff I mention here. As I said, this is far too large a problem to have
an effective answer from a form like this.
Sent from Mail for Windows 10
Sent: May 15, 2017 1:02 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Observing low RX throughput for 10G ethernet NIC
Thanks for your valuable comments....
In our driver there is no polling mode for processing of the packets....
The processing of the packet is done on DPC mode once the ISR's DPC function is
For polling mechanism, Do we need to poll for the RX packets on the different
CPU with creating a thread for handling it.
NTDEV is sponsored by OSR
Visit the list online at:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
To unsubscribe, visit the List Server section of OSR Online at