All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: netdev@vger.kernel.org
Cc: bpf@vger.kernel.org, "Daniel Borkmann" <daniel@iogearbox.net>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"David Miller" <davem@davemloft.net>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>
Subject: [PATCH bpf-next v3 0/3] xdp: Introduce bulking for non-map XDP_REDIRECT
Date: Thu, 16 Jan 2020 16:14:42 +0100	[thread overview]
Message-ID: <157918768284.1458396.8128704597152008763.stgit@toke.dk> (raw)

Since commit 96360004b862 ("xdp: Make devmap flush_list common for all map
instances"), devmap flushing is a global operation instead of tied to a
particular map. This means that with a bit of refactoring, we can finally fix
the performance delta between the bpf_redirect_map() and bpf_redirect() helper
functions, by introducing bulking for the latter as well.

This series makes this change by moving the data structure used for the bulking
into struct net_device itself, so we can access it even when there is not
devmap. Once this is done, moving the bpf_redirect() helper to use the bulking
mechanism becomes quite trivial, and brings bpf_redirect() up to the same as
bpf_redirect_map():

                       Before:   After:
1 CPU:
bpf_redirect_map:      8.4 Mpps  8.4 Mpps  (no change)
bpf_redirect:          5.0 Mpps  8.4 Mpps  (+68%)
2 CPUs:
bpf_redirect_map:     15.9 Mpps  16.1 Mpps  (+1% or ~no change)
bpf_redirect:          9.5 Mpps  15.9 Mpps  (+67%)

After this patch series, the only semantics different between the two variants
of the bpf() helper (apart from the absence of a map argument, obviously) is
that the _map() variant will return an error if passed an invalid map index,
whereas the bpf_redirect() helper will succeed, but drop packets on
xdp_do_redirect(). This is because the helper has no reference to the calling
netdev, so unfortunately we can't do the ifindex lookup directly in the helper.

Changelog:

v3:
  - Switch two more fields to avoid a list_head spanning two cache lines
  - Include Jesper's tracepoint patch
  - Also rename xdp_do_flush_map()
  - Fix a few nits from Maciej

v2:
  - Consolidate code paths and tracepoints for map and non-map redirect variants
    (Björn)
  - Add performance data for 2-CPU test (Jesper)
  - Move fields to avoid shifting cache lines in struct net_device (Eric)

---

Jesper Dangaard Brouer (1):
      devmap: Adjust tracepoint for map-less queue flush

Toke Høiland-Jørgensen (2):
      xdp: Move devmap bulk queue into struct net_device
      xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths


 drivers/net/tun.c              |    4 +
 drivers/net/veth.c             |    2 -
 drivers/net/virtio_net.c       |    2 -
 include/linux/bpf.h            |   13 +++-
 include/linux/filter.h         |   10 ++-
 include/linux/netdevice.h      |   13 ++--
 include/trace/events/xdp.h     |  130 +++++++++++++++++-----------------------
 kernel/bpf/devmap.c            |   95 +++++++++++++++--------------
 net/core/dev.c                 |    2 +
 net/core/filter.c              |   90 ++++++----------------------
 samples/bpf/xdp_monitor_kern.c |    8 +-
 11 files changed, 160 insertions(+), 209 deletions(-)


             reply	other threads:[~2020-01-16 15:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 15:14 Toke Høiland-Jørgensen [this message]
2020-01-16 15:14 ` [PATCH bpf-next v3 1/3] xdp: Move devmap bulk queue into struct net_device Toke Høiland-Jørgensen
2020-01-16 15:14 ` [PATCH bpf-next v3 2/3] xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths Toke Høiland-Jørgensen
2020-01-16 15:14 ` [PATCH bpf-next v3 3/3] devmap: Adjust tracepoint for map-less queue flush Toke Høiland-Jørgensen
2020-01-17  4:06 ` [PATCH bpf-next v3 0/3] xdp: Introduce bulking for non-map XDP_REDIRECT Alexei Starovoitov

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=157918768284.1458396.8128704597152008763.stgit@toke.dk \
    --to=toke@redhat.com \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.