On 2019/10/21 20:23, Björn Töpel wrote:

On Sat, 19 Oct 2019 at 00:31, Toshiaki Makita
[off-list ref] wrote:

quoted

[...]

quoted

* About OVS AF_XDP netdev

Recently OVS has added AF_XDP netdev type support. This also makes use
of XDP, but in some ways different from this patch set.

- AF_XDP work originally started in order to bring BPF's flexibility to
   OVS, which enables us to upgrade datapath without updating kernel.
   AF_XDP solution uses userland datapath so it achieved its goal.
   xdp_flow will not replace OVS datapath completely, but offload it
   partially just for speed up.

- OVS AF_XDP requires PMD for the best performance so consumes 100% CPU
   as well as using another core for softirq.

Disclaimer; I haven't studied the OVS AF_XDP code, so this is about
AF_XDP in general.

One of the nice things about AF_XDP is that it *doesn't* force a user
to busy-poll (burn CPUs) like a regular userland pull-mode driver.
Yes, you can do that if you're extremely latency sensitive, but for
most users (and I think some OVS deployments might fit into this
category) not pinning cores/interrupts and using poll() syscalls (need
wakeup patch [1]) is the way to go. The scenario you're describing
with ksoftirqd spinning on one core, and user application on another
is not something I'd recommend, rather run your packet processing
application on one core together with the softirq processing.

Thank you for the information.
I want to evaluate AF_XDP solution more appropriately.

William, please correct me if I'm saying something wrong here.
Or guide me if more appropriate configuration to achieve best performance is possible.

Björn
[1] https://lore.kernel.org/bpf/1565767643-4908-1-git-send-email-magnus.karlsson@intel.com/#t (local)

Toshiaki Makita