From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Toshiaki Makita <toshiaki.makita1@gmail.com>
Cc: netdev@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>,
Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
Date: Mon, 23 Jul 2018 18:02:46 -0700 [thread overview]
Message-ID: <20180723180246.1836bc11@cakuba.netronome.com> (raw)
In-Reply-To: <20180722151308.5480-6-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> This allows NIC's XDP to redirect packets to veth. The destination veth
> device enqueues redirected packets to the napi ring of its peer, then
> they are processed by XDP on its peer veth device.
> This can be thought as calling another XDP program by XDP program using
> REDIRECT, when the peer enables driver XDP.
>
> Note that when the peer veth device does not set driver xdp, redirected
> packets will be dropped because the peer is not ready for NAPI.
Often we can't redirect to devices which don't have am xdp program
installed. In your case we can't redirect unless the peer of the
target doesn't have a program installed? :(
Perhaps it is time to reconsider what Saeed once asked for, a flag or
attribute to enable being the destination of a XDP_REDIRECT.
> v2:
> - Drop the part converting xdp_frame into skb when XDP is not enabled.
> - Implement bulk interface of ndo_xdp_xmit.
> - Implement XDP_XMIT_FLUSH bit and drop ndo_xdp_flush.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> drivers/net/veth.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 4be75c58bc6a..57187e955fea 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -17,6 +17,7 @@
> #include <net/rtnetlink.h>
> #include <net/dst.h>
> #include <net/xfrm.h>
> +#include <net/xdp.h>
> #include <linux/veth.h>
> #include <linux/module.h>
> #include <linux/bpf.h>
> @@ -125,6 +126,11 @@ static void *veth_ptr_to_xdp(void *ptr)
> return (void *)((unsigned long)ptr & ~VETH_XDP_FLAG);
> }
>
> +static void *veth_xdp_to_ptr(void *ptr)
> +{
> + return (void *)((unsigned long)ptr | VETH_XDP_FLAG);
> +}
> +
> static void veth_ptr_free(void *ptr)
> {
> if (veth_is_xdp_frame(ptr))
> @@ -267,6 +273,44 @@ static struct sk_buff *veth_build_skb(void *head, int headroom, int len,
> return skb;
> }
>
> +static int veth_xdp_xmit(struct net_device *dev, int n,
> + struct xdp_frame **frames, u32 flags)
> +{
> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
> + struct net_device *rcv;
> + int i, drops = 0;
> +
> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
> + return -EINVAL;
> +
> + rcv = rcu_dereference(priv->peer);
> + if (unlikely(!rcv))
> + return -ENXIO;
> +
> + rcv_priv = netdev_priv(rcv);
> + /* xdp_ring is initialized on receive side? */
> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
> + return -ENXIO;
> +
> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
> + for (i = 0; i < n; i++) {
> + struct xdp_frame *frame = frames[i];
> + void *ptr = veth_xdp_to_ptr(frame);
> +
> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
Would you mind sparing a few more words how this is safe vs the
.ndo_close() on the peer? Personally I'm a bit uncomfortable with the
IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
guarantee the device doesn't go down right after that check, or is
already down, but netdev->flags are not atomic...
> + xdp_return_frame_rx_napi(frame);
> + drops++;
> + }
> + }
> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
> +
> + if (flags & XDP_XMIT_FLUSH)
> + __veth_xdp_flush(rcv_priv);
> +
> + return n - drops;
> +}
> +
> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
> struct xdp_frame *frame)
> {
> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
> .ndo_features_check = passthru_features_check,
> .ndo_set_rx_headroom = veth_set_rx_headroom,
> .ndo_bpf = veth_xdp,
> + .ndo_xdp_xmit = veth_xdp_xmit,
> };
>
> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
next prev parent reply other threads:[~2018-07-24 2:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-22 15:13 [PATCH v3 bpf-next 0/8] veth: Driver XDP Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 1/8] net: Export skb_headers_offset_update Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 2/8] veth: Add driver XDP Toshiaki Makita
2018-07-24 0:23 ` Jakub Kicinski
2018-07-24 1:47 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled Toshiaki Makita
2018-07-24 0:27 ` Jakub Kicinski
2018-07-24 1:56 ` Toshiaki Makita
2018-07-24 9:39 ` Toshiaki Makita
2018-07-24 19:10 ` Jakub Kicinski
2018-07-25 4:22 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 4/8] veth: Handle xdp_frames in xdp napi ring Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit Toshiaki Makita
2018-07-24 0:19 ` kbuild test robot
2018-07-24 1:59 ` Toshiaki Makita
2018-07-24 0:33 ` kbuild test robot
2018-07-24 1:02 ` Jakub Kicinski [this message]
2018-07-24 2:11 ` Toshiaki Makita
2018-07-24 13:58 ` Tariq Toukan
2018-07-24 2:24 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info Toshiaki Makita
2018-07-24 1:22 ` Jakub Kicinski
2018-07-24 2:43 ` Toshiaki Makita
2018-07-24 3:38 ` Jakub Kicinski
2018-07-24 4:02 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 7/8] veth: Add XDP TX and REDIRECT Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 8/8] veth: Support per queue XDP ring Toshiaki Makita
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=20180723180246.1836bc11@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=makita.toshiaki@lab.ntt.co.jp \
--cc=netdev@vger.kernel.org \
--cc=toshiaki.makita1@gmail.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.