All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: David Ahern <dsahern@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	prashantbhole.linux@gmail.com, jasowang@redhat.com,
	toke@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, David Ahern <dahern@digitalocean.com>,
	brouer@redhat.com
Subject: Re: [PATCH v2 bpf-next 06/17] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path
Date: Fri, 24 Apr 2020 11:56:16 +0200	[thread overview]
Message-ID: <20200424115616.77a5689c@carbon> (raw)
In-Reply-To: <20200424021148.83015-7-dsahern@kernel.org>

On Thu, 23 Apr 2020 20:11:37 -0600
David Ahern <dsahern@kernel.org> wrote:

> Running programs in the egress path, on skbs or xdp_frames, does not
> require driver specific resources like Rx path. Accordingly, the
> programs can be run in core code, so add xdp_egress_prog to net_device
> to hold a reference to an attached program.

I disagree.  The TX path does need driver specific resources, most
importantly information about the TX-queue that was used.

That said, I think this patch is the right design, to place this more
centrally in the net-core code, as driver changes are harder to
maintain and generally painful (I speak from experience ;-)).

After this patchset goes in, we need continue this work, and find a
solution for the XDP-redirect overflow problem, and TX-queue selection.
We might still have some driver work ahead, as I think we can change the
ndo_xdp_xmit() API, to give us the information I'm looking for.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


  parent reply	other threads:[~2020-04-24  9:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24  2:11 [PATCH v2 bpf-next 00/17] net: Add support for XDP in egress path David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 01/17] net: Refactor convert_to_xdp_frame David Ahern
2020-04-24  7:27   ` Jesper Dangaard Brouer
2020-04-24  2:11 ` [PATCH v2 bpf-next 02/17] net: Move handling of IFLA_XDP attribute out of do_setlink David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 03/17] net: Add XDP setup and query commands for Tx programs David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 04/17] net: Add BPF_XDP_EGRESS as a bpf_attach_type David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 05/17] xdp: Add xdp_txq_info to xdp_buff David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 06/17] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path David Ahern
2020-04-24  8:57   ` Toke Høiland-Jørgensen
2020-04-24 20:23     ` David Ahern
2020-04-24  9:56   ` Jesper Dangaard Brouer [this message]
2020-04-24  2:11 ` [PATCH v2 bpf-next 07/17] net: Rename do_xdp_generic to do_xdp_generic_rx David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 08/17] net: rename netif_receive_generic_xdp to do_generic_xdp_core David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 09/17] net: set XDP egress program on netdevice David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 10/17] net: Support xdp in the Tx path for packets as an skb David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 11/17] net: Support xdp in the Tx path for xdp_frames David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 12/17] libbpf: Refactor get_xdp_info David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 13/17] libbpf: Add egress XDP support David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 14/17] bpftool: Add support for XDP egress David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 15/17] selftest: Add test for xdp_egress David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 16/17] selftest: Add xdp_egress attach tests David Ahern
2020-04-24  2:11 ` [PATCH v2 bpf-next 17/17] samples/bpf: add XDP egress support to xdp1 David Ahern
2020-04-24  4:25 ` [PATCH v2 bpf-next 00/17] net: Add support for XDP in egress path David Ahern

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=20200424115616.77a5689c@carbon \
    --to=brouer@redhat.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=dahern@digitalocean.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=toke@redhat.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.