[Intel-wired-lan] [RFC PATCH bpf-next 0/9] Introduce biased busy-polling
bjorn.topel at intel.com
Wed Oct 28 15:14:59 UTC 2020
On 2020-10-28 15:13, Eric Dumazet wrote:
> On Wed, Oct 28, 2020 at 2:35 PM Björn Töpel <bjorn.topel at gmail.com> wrote:
>> Performance UDP sockets:
>> I hacked netperf to use non-blocking sockets, and looping over
>> recvfrom(). The following command-line was used:
>> $ netperf -H 192.168.1.1 -l 30 -t UDP_RR -v 2 -- \
>> -o min_latency,mean_latency,max_latency,stddev_latency,transaction_rate
>> Non-blocking with biased busy-polling:
> But a fair comparison should be done using current busy-polling mode,
> which does not require netperf to use non-blocking mode in the first place ?
Yeah, good point! I'll make sure to add that.
One difference between biased/regular is that for elephant flows,
regular falls back to softirq processing, where as the biased stay in
"busy-polling mode". Further, if the softirq is really busy due to heavy
load (traffic) busy-polling will never be entered.
> Would disabling/rearming interrupts about 60,000 times per second
> bring any benefit ?
Not following, Eric. Wdym?
> Additional questions :
> - What happens to the gro_flush_timeout and accumulated TCP segments
> in GRO engine
> while the biased busy-polling is in use ?
> - What mechanism would avoid a potential 200 ms latency when the
> application wants to exit cleanly ?
> Presumably when/if SO_BIAS_BUSY_POLL is used to clear
> sk->sk_bias_busy_poll we need
> to make sure device interrupts are re-enabled.
Yes, good questions/input. I'll look into the first one. As for the
second one; I'd say this should be implemented! Thanks!
More information about the Intel-wired-lan