Merge branch 'bpf-sample-cpumap-lb'
authorDaniel Borkmann <daniel@iogearbox.net>
Fri, 10 Aug 2018 14:07:50 +0000 (16:07 +0200)
committerDaniel Borkmann <daniel@iogearbox.net>
Fri, 10 Aug 2018 14:07:51 +0000 (16:07 +0200)
commitc4c20217542469b9caf7f700ac9a2eeb32cb3742
tree445df34e43e9a988597c5ff8f1654d235e3aedb4
parenteb91e4d4db06adef06e7f50c02813c13c6ca5a5b
parent1bca4e6b1863c0a006fde6a66720a87823109294
Merge branch 'bpf-sample-cpumap-lb'

Jesper Dangaard Brouer says:

====================
Background: cpumap moves the SKB allocation out of the driver code,
and instead allocate it on the remote CPU, and invokes the regular
kernel network stack with the newly allocated SKB.

The idea behind the XDP CPU redirect feature, is to use XDP as a
load-balancer step in-front of regular kernel network stack.  But the
current sample code does not provide a good example of this.  Part of
the reason is that, I have implemented this as part of Suricata XDP
load-balancer.

Given this is the most frequent feature request I get.  This patchset
implement the same XDP load-balancing as Suricata does, which is a
symmetric hash based on the IP-pairs + L4-protocol.

The expected setup for the use-case is to reduce the number of NIC RX
queues via ethtool (as XDP can handle more per core), and via
smp_affinity assign these RX queues to a set of CPUs, which will be
handling RX packets.  The CPUs that runs the regular network stack is
supplied to the sample xdp_redirect_cpu tool by specifying
the --cpu option multiple times on the cmdline.

I do note that cpumap SKB creation is not feature complete yet, and
more work is coming.  E.g. given GRO is not implemented yet, do expect
TCP workloads to be slower.  My measurements do indicate UDP workloads
are faster.
====================

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>