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, mst@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 RFC v4 bpf-next 09/11] tun: Support xdp in the Tx path for xdp_frames
Date: Tue, 3 Mar 2020 11:40:44 +0100	[thread overview]
Message-ID: <20200303114044.2c7482d5@carbon> (raw)
In-Reply-To: <20200227032013.12385-10-dsahern@kernel.org>

On Wed, 26 Feb 2020 20:20:11 -0700
David Ahern <dsahern@kernel.org> wrote:

> From: David Ahern <dahern@digitalocean.com>
> 
> Add support to run Tx path program on packets arriving at a tun
> device via XDP redirect.
> 
> XDP_TX return code means move the packet to the Tx path of the device.
> For a program run in the Tx / egress path, XDP_TX is essentially the
> same as "continue on" which is XDP_PASS.
> 
> Conceptually, XDP_REDIRECT for this path can work the same as it
> does for the Rx path, but that return code is left for a follow
> on series.
> 
> Signed-off-by: Prashant Bhole <prashantbhole.linux@gmail.com>
> Signed-off-by: David Ahern <dahern@digitalocean.com>
> ---
>  drivers/net/tun.c | 49 +++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 47 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index dcae6521a39d..d3fc7e921c85 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1359,10 +1359,50 @@ static void __tun_xdp_flush_tfile(struct tun_file *tfile)
>  	tfile->socket.sk->sk_data_ready(tfile->socket.sk);
>  }
>  
> +static u32 tun_do_xdp_tx(struct tun_struct *tun, struct tun_file *tfile,
> +			 struct xdp_frame *frame, struct xdp_txq_info *txq)
> +{
> +	struct bpf_prog *xdp_prog;
> +	u32 act = XDP_PASS;
> +
> +	xdp_prog = rcu_dereference(tun->xdp_egress_prog);
> +	if (xdp_prog) {
> +		struct xdp_buff xdp;
> +
> +		xdp.data_hard_start = frame->data - frame->headroom;

This is correct, only because frame->headroom have been reduced with
sizeof(*xdp_frame), as we want to avoid that the BPF-prog have access
to xdp_frame memory.  Remember that memory storing xdp_frame in located
in the top of the payload/page.


> +		xdp.data = frame->data;
> +		xdp.data_end = xdp.data + frame->len;
> +		xdp_set_data_meta_invalid(&xdp);
> +		xdp.txq = txq;
> +
> +		act = bpf_prog_run_xdp(xdp_prog, &xdp);

The BPF-prog can change/adjust headroom and tailroom (tail only shrink,
but I'm working on extending this).  Thus, you need to adjust the
xdp_frame accordingly afterwards.

(The main use-case is pushing on a header, right?)

> +		switch (act) {
> +		case XDP_TX:    /* for Tx path, XDP_TX == XDP_PASS */
> +			act = XDP_PASS;
> +			break;
> +		case XDP_PASS:
> +			break;
> +		case XDP_REDIRECT:
> +			/* fall through */
> +		default:
> +			bpf_warn_invalid_xdp_action(act);
> +			/* fall through */
> +		case XDP_ABORTED:
> +			trace_xdp_exception(tun->dev, xdp_prog, act);
> +			/* fall through */
> +		case XDP_DROP:
> +			break;
> +		}
> +	}
> +
> +	return act;
> +}
> +
>  static int tun_xdp_xmit(struct net_device *dev, int n,
>  			struct xdp_frame **frames, u32 flags)
>  {
>  	struct tun_struct *tun = netdev_priv(dev);
> +	struct xdp_txq_info txq = { .dev = dev };
>  	struct tun_file *tfile;
>  	u32 numqueues;
>  	int drops = 0;
> @@ -1389,12 +1429,17 @@ static int tun_xdp_xmit(struct net_device *dev, int n,
>  	spin_lock(&tfile->tx_ring.producer_lock);
>  	for (i = 0; i < n; i++) {
>  		struct xdp_frame *xdp = frames[i];
> +		void *frame;
> +
> +		if (tun_do_xdp_tx(tun, tfile, xdp, &txq) != XDP_PASS)
> +			goto drop;
> +
>  		/* Encode the XDP flag into lowest bit for consumer to differ
>  		 * XDP buffer from sk_buff.
>  		 */
> -		void *frame = tun_xdp_to_ptr(xdp);
> -
> +		frame = tun_xdp_to_ptr(xdp);
>  		if (__ptr_ring_produce(&tfile->tx_ring, frame)) {
> +drop:
>  			this_cpu_inc(tun->pcpu_stats->tx_dropped);
>  			xdp_return_frame_rx_napi(xdp);
>  			drops++;



-- 
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-03-03 10:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  3:20 [PATCH RFC v4 bpf-next 00/11] Add support for XDP in egress path David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 01/11] net: Add XDP setup and query commands for Tx programs David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 02/11] net: Add BPF_XDP_EGRESS as a bpf_attach_type David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 03/11] xdp: Add xdp_txq_info to xdp_buff David Ahern
2020-02-27  8:00   ` Jesper Dangaard Brouer
2020-02-27 11:58     ` Toke Høiland-Jørgensen
2020-02-28  3:01       ` David Ahern
2020-02-28 10:10         ` Toke Høiland-Jørgensen
2020-02-27 20:44     ` David Ahern
2020-02-28 10:07       ` Toke Høiland-Jørgensen
2020-02-28 10:41         ` Jesper Dangaard Brouer
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 04/11] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 05/11] net: core: rename netif_receive_generic_xdp to do_generic_xdp_core David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 06/11] net: core: Rename do_xdp_generic to do_xdp_generic_rx and export David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 07/11] tun: set egress XDP program David Ahern
2020-03-02  3:32   ` Jason Wang
2020-03-02  3:52     ` David Ahern
2020-03-10  2:18     ` David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 08/11] tun: Support xdp in the Tx path for skb David Ahern
2020-03-02  3:28   ` Jason Wang
2020-03-02  3:41     ` David Ahern
2020-03-03 10:46   ` Jesper Dangaard Brouer
2020-03-03 15:36     ` David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 09/11] tun: Support xdp in the Tx path for xdp_frames David Ahern
2020-03-02 18:30   ` Alexei Starovoitov
2020-03-03  4:27     ` David Ahern
2020-03-03  9:08       ` Jesper Dangaard Brouer
2020-03-03 18:16       ` Alexei Starovoitov
2020-03-03 10:40   ` Jesper Dangaard Brouer [this message]
2020-03-10  3:06     ` David Ahern
2020-03-10  3:44       ` David Ahern
2020-03-10  9:03         ` Jesper Dangaard Brouer
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 10/11] libbpf: Add egress XDP support David Ahern
2020-02-27  3:20 ` [PATCH RFC v4 bpf-next 11/11] samples/bpf: xdp1, add " David Ahern
2020-02-27 11:55 ` [PATCH RFC v4 bpf-next 00/11] Add support for XDP in egress path Toke Høiland-Jørgensen
2020-02-27 16:22   ` Alexei Starovoitov
2020-02-27 17:06     ` Toke Høiland-Jørgensen
2020-02-27 18:37       ` 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=20200303114044.2c7482d5@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=mst@redhat.com \
    --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.