All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: David Ahern <dsahern@kernel.org>, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org,
	prashantbhole.linux@gmail.com, jasowang@redhat.com,
	brouer@redhat.com, toshiaki.makita1@gmail.com,
	daniel@iogearbox.net, john.fastabend@gmail.com, ast@kernel.org,
	kafai@fb.com, songliubraving@fb.com, yhs@fb.com, andriin@fb.com,
	dsahern@gmail.com
Subject: Re: [PATCH RFC-v5 bpf-next 00/12] Add support for XDP in egress path
Date: Thu, 16 Apr 2020 15:59:39 +0200	[thread overview]
Message-ID: <87pnc7lees.fsf@toke.dk> (raw)
In-Reply-To: <20200413171801.54406-1-dsahern@kernel.org>

David Ahern <dsahern@kernel.org> writes:

> From: David Ahern <dsahern@gmail.com>
>
> This series adds support for XDP in the egress path by introducing
> a new XDP attachment type, BPF_XDP_EGRESS, and adding a UAPI to
> if_link.h for attaching the program to a netdevice and reporting
> the program. bpf programs can be run on all packets in the Tx path -
> skbs or redirected xdp frames. The intent is to emulate the current
> RX path for XDP as much as possible to maintain consistency and
> symmetry in the 2 paths with their APIs.
>
> This is a missing primitive for XDP allowing solutions to build small,
> targeted programs properly distributed in the networking path allowing,
> for example, an egress firewall/ACL/traffic verification or packet
> manipulation and encapping an entire ethernet frame whether it is
> locally generated traffic, forwarded via the slow path (ie., full
> stack processing) or xdp redirected frames.
>
> Nothing about running a program in the Tx path requires driver specific
> resources like the Rx path has. Thus, programs can be run in core
> code and attached to the net_device struct similar to skb mode. The
> existing XDP_FLAGS_*_MODE are not relevant at the moment, so none can
> be set in the attach. XDP_FLAGS_HW_MODE can be used in the future
> (e.g., the work on offloading programs from a VM).
>
> The locations chosen to run the egress program - __netdev_start_xmit
> before the call to ndo_start_xmit and bq_xmit_all before invoking
> ndo_xdp_xmit - allow follow on patch sets to handle tx queueing and
> setting the queue index if multi-queue with consistency in handling
> both packet formats.

I like the choice of hook points. It is interesting that it implies that
there will not be not a separate "XDP generic" hook on egress. And it's
certainly a benefit to not have to change all the drivers. So that's
good :)

I also think it'll be possible to get the information we want (such as
TXQ fill level) at the places you put the hooks. For the skb case
through struct netdev_queue and BQL, and for REDIRECT presumably with
Magnus' queue abstraction once that lands. So overall I think we're
getting there :)

I'll add a few more comments for each patch...

-Toke


  parent reply	other threads:[~2020-04-16 14:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 17:17 [PATCH RFC-v5 bpf-next 00/12] Add support for XDP in egress path David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 01/12] net: Add XDP setup and query commands for Tx programs David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 02/12] net: Add BPF_XDP_EGRESS as a bpf_attach_type David Ahern
2020-04-16 14:01   ` Toke Høiland-Jørgensen
2020-04-16 16:35     ` David Ahern
2020-04-17  9:23       ` Toke Høiland-Jørgensen
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 03/12] xdp: Add xdp_txq_info to xdp_buff David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 04/12] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 05/12] net: core: rename netif_receive_generic_xdp to do_generic_xdp_core David Ahern
2020-04-16 14:00   ` Toke Høiland-Jørgensen
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 06/12] net: core: Rename do_xdp_generic to do_xdp_generic_rx David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 07/12] dev: set egress XDP program David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 08/12] dev: Support xdp in the Tx path for packets as an skb David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 09/12] dev: Support xdp in the Tx path for xdp_frames David Ahern
2020-04-16 14:02   ` Toke Høiland-Jørgensen
2020-04-16 23:50     ` David Ahern
2020-04-17  9:25       ` Toke Høiland-Jørgensen
2020-04-17 20:06         ` David Ahern
2020-04-17  8:30   ` Jesper Dangaard Brouer
2020-04-17 21:29     ` David Ahern
2020-04-13 17:17 ` [PATCH RFC-v5 bpf-next 10/12] libbpf: Add egress XDP support David Ahern
2020-04-13 17:18 ` [PATCH RFC-v5 bpf-next 11/12] bpftool: Add support for XDP egress David Ahern
2020-04-13 17:18 ` [PATCH RFC-v5 bpf-next 12/12] samples/bpf: add XDP egress support to xdp1 David Ahern
2020-04-15 15:01   ` Alexei Starovoitov
2020-04-16 13:59 ` Toke Høiland-Jørgensen [this message]
2020-04-16 23:55   ` [PATCH RFC-v5 bpf-next 00/12] Add support for XDP in egress path David Ahern
2020-04-17  9:28     ` Toke Høiland-Jørgensen

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=87pnc7lees.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=jasowang@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=prashantbhole.linux@gmail.com \
    --cc=songliubraving@fb.com \
    --cc=toshiaki.makita1@gmail.com \
    --cc=yhs@fb.com \
    /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.