From: Jesper Dangaard Brouer <brouer@redhat.com>
To: netdev@vger.kernel.org, Jesper Dangaard Brouer <brouer@redhat.com>
Cc: victor@inliniac.net, eric@regit.org,
Daniel Borkmann <borkmann@iogearbox.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
jhsiao@redhat.com
Subject: [bpf-next V2 PATCH 0/2] Implement sample code for XDP cpumap IP-pair load-balancing
Date: Fri, 10 Aug 2018 14:02:52 +0200 [thread overview]
Message-ID: <153390254528.10825.9125109091513926669.stgit@firesoul> (raw)
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.
---
Jesper Dangaard Brouer (2):
samples/bpf: add Paul Hsieh's (LGPL 2.1) hash function SuperFastHash
samples/bpf: xdp_redirect_cpu load balance like Suricata
samples/bpf/hash_func01.h | 55 +++++++++++++++++++
samples/bpf/xdp_redirect_cpu_kern.c | 103 +++++++++++++++++++++++++++++++++++
samples/bpf/xdp_redirect_cpu_user.c | 4 +
3 files changed, 160 insertions(+), 2 deletions(-)
create mode 100644 samples/bpf/hash_func01.h
next reply other threads:[~2018-08-10 14:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-10 12:02 Jesper Dangaard Brouer [this message]
2018-08-10 12:02 ` [bpf-next V2 PATCH 1/2] samples/bpf: add Paul Hsieh's (LGPL 2.1) hash function SuperFastHash Jesper Dangaard Brouer
2018-08-10 12:03 ` [bpf-next V2 PATCH 2/2] samples/bpf: xdp_redirect_cpu load balance like Suricata Jesper Dangaard Brouer
2018-08-10 14:10 ` [bpf-next V2 PATCH 0/2] Implement sample code for XDP cpumap IP-pair load-balancing Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=153390254528.10825.9125109091513926669.stgit@firesoul \
--to=brouer@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=borkmann@iogearbox.net \
--cc=eric@regit.org \
--cc=jhsiao@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=victor@inliniac.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox