AF_XDP new prefer busy poll

Dan Siemon <[email protected]>
Newsgroups org.kernel.vger.xdp-newbies
Message-ID <[email protected]>
I've started working on adding SO_PREFER_BUSY_POLL [1] to afxdp-rs [2].
I have a few questions that I haven't been able to answer definitively
from docs or commits.

1) To confirm, configuration like the below is required?

echo 2 | sudo tee /sys/class/net/ens785f1/napi_defer_hard_irqs
echo 200000 | sudo tee /sys/class/net/ens785f1/gro_flush_timeout

2) It's not clear to me what polling operations are required. It looks
like the xdpdock example was modified to call recvfrom() and sendto()
in every situation where previously the condition was that the
need_wakeup flag was set on one of the queues. It looks like this
structure may do extra syscalls?

It it sufficient to 'poll' (I don't mean the syscall here) the socket
once with one syscall operation or do we need the equivalent of a send
and recv operation (like the example) in each loop iteration?

3) The patch linked below mentions adding recvmsg and sendmsg support
for busy polling. The xdpsock example uses recvfrom(). What is the set
of syscalls that can drive the busy polling? Is there a recommendation
for which one(s) should be used?

4) In situations where there are multiple sockets, will it work to do
one poll syscall with multiple fds to reduce the number of syscalls? Is
that a good idea?

5)

"If the application stops performing busy-polling via a system call,
the watchdog timer defined by gro_flush_timeout will timeout, and
regular softirq handling will resume."

Does this imply that if the application fails to poll within the
watchdog time that it needs to take action to get back into prefer busy
polling mode?

On the plus side, the initial performance numbers look good but there
are a lot of drops as traffic ramps up that I haven't figured out the
cause of yet. There are no drops once it's running in a steady state.

Thanks for any help or insight.

[1] - https://lwn.net/Articles/837010/
[2] - https://github.com/aterlo/afxdp-rs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.