| Message ID | 20210416154745.238804-1-toke@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 0e672f306a28ddd55d2fb2ab89afdc615b5324a4 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] veth: check for NAPI instead of xdp_prog before xmit of XDP frame | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | warning | 5 maintainers not CCed: yhs@fb.com kpsingh@kernel.org andrii@kernel.org kafai@fb.com songliubraving@fb.com |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | fail | Link |
| netdev/checkpatch | warning | WARNING: Unknown commit id '6788fa154546', maybe rebased or not pulled? |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
On Fri, 16 Apr 2021 17:47:45 +0200 Toke Høiland-Jørgensen <toke@redhat.com> wrote: > The recent patch that tied enabling of veth NAPI to the GRO flag also has > the nice side effect that a veth device can be the target of an > XDP_REDIRECT without an XDP program needing to be loaded on the peer > device. However, the patch adding this extra NAPI mode didn't actually > change the check in veth_xdp_xmit() to also look at the new NAPI pointer, > so let's fix that. > > Fixes: 6788fa154546 ("veth: allow enabling NAPI even without XDP") > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> > --- > drivers/net/veth.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Very happy to see this strange requirement of loading an xdp_prog on the veth peer (inside the netns) being lifted. Multiple people/users have hit this issue and complained. Thanks for the followup to fix this! :-) > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > index 15b2e3923c47..bdb7ce3cb054 100644 > --- a/drivers/net/veth.c > +++ b/drivers/net/veth.c > @@ -486,11 +486,10 @@ static int veth_xdp_xmit(struct net_device *dev, int n, > > rcv_priv = netdev_priv(rcv); > rq = &rcv_priv->rq[veth_select_rxq(rcv)]; > - /* Non-NULL xdp_prog ensures that xdp_ring is initialized on receive > - * side. This means an XDP program is loaded on the peer and the peer > - * device is up. > + /* The napi pointer is set if NAPI is enabled, which ensures that > + * xdp_ring is initialized on receive side and the peer device is up. > */ > - if (!rcu_access_pointer(rq->xdp_prog)) > + if (!rcu_access_pointer(rq->napi)) > goto out; > > max_len = rcv->mtu + rcv->hard_header_len + VLAN_HLEN;
On Fri, 2021-04-16 at 17:47 +0200, Toke Høiland-Jørgensen wrote: > The recent patch that tied enabling of veth NAPI to the GRO flag also has > the nice side effect that a veth device can be the target of an > XDP_REDIRECT without an XDP program needing to be loaded on the peer > device. However, the patch adding this extra NAPI mode didn't actually > change the check in veth_xdp_xmit() to also look at the new NAPI pointer, > so let's fix that. > > Fixes: 6788fa154546 ("veth: allow enabling NAPI even without XDP") > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> > --- > drivers/net/veth.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > index 15b2e3923c47..bdb7ce3cb054 100644 > --- a/drivers/net/veth.c > +++ b/drivers/net/veth.c > @@ -486,11 +486,10 @@ static int veth_xdp_xmit(struct net_device *dev, int n, > > rcv_priv = netdev_priv(rcv); > rq = &rcv_priv->rq[veth_select_rxq(rcv)]; > - /* Non-NULL xdp_prog ensures that xdp_ring is initialized on receive > - * side. This means an XDP program is loaded on the peer and the peer > - * device is up. > + /* The napi pointer is set if NAPI is enabled, which ensures that > + * xdp_ring is initialized on receive side and the peer device is up. > */ > - if (!rcu_access_pointer(rq->xdp_prog)) > + if (!rcu_access_pointer(rq->napi)) > goto out; > > max_len = rcv->mtu + rcv->hard_header_len + VLAN_HLEN; Acked-by: Paolo Abeni <pabeni@redhat.com> Thanks for the quick turn-around!
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Fri, 16 Apr 2021 17:47:45 +0200 you wrote: > The recent patch that tied enabling of veth NAPI to the GRO flag also has > the nice side effect that a veth device can be the target of an > XDP_REDIRECT without an XDP program needing to be loaded on the peer > device. However, the patch adding this extra NAPI mode didn't actually > change the check in veth_xdp_xmit() to also look at the new NAPI pointer, > so let's fix that. > > [...] Here is the summary with links: - [net-next] veth: check for NAPI instead of xdp_prog before xmit of XDP frame https://git.kernel.org/netdev/net-next/c/0e672f306a28 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
diff --git a/drivers/net/veth.c b/drivers/net/veth.c index 15b2e3923c47..bdb7ce3cb054 100644 --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -486,11 +486,10 @@ static int veth_xdp_xmit(struct net_device *dev, int n, rcv_priv = netdev_priv(rcv); rq = &rcv_priv->rq[veth_select_rxq(rcv)]; - /* Non-NULL xdp_prog ensures that xdp_ring is initialized on receive - * side. This means an XDP program is loaded on the peer and the peer - * device is up. + /* The napi pointer is set if NAPI is enabled, which ensures that + * xdp_ring is initialized on receive side and the peer device is up. */ - if (!rcu_access_pointer(rq->xdp_prog)) + if (!rcu_access_pointer(rq->napi)) goto out; max_len = rcv->mtu + rcv->hard_header_len + VLAN_HLEN;
The recent patch that tied enabling of veth NAPI to the GRO flag also has the nice side effect that a veth device can be the target of an XDP_REDIRECT without an XDP program needing to be loaded on the peer device. However, the patch adding this extra NAPI mode didn't actually change the check in veth_xdp_xmit() to also look at the new NAPI pointer, so let's fix that. Fixes: 6788fa154546 ("veth: allow enabling NAPI even without XDP") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> --- drivers/net/veth.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)