From: Stephen Hemminger <stephen@networkplumber.org>
To: Saeed Mahameed <saeedm@mellanox.com>
Cc: "jiri@resnulli.us" <jiri@resnulli.us>,
"jesper.brouer@gmail.com" <jesper.brouer@gmail.com>,
"sthemmin@microsoft.com" <sthemmin@microsoft.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] net: core: support XDP generic on stacked devices.
Date: Thu, 23 May 2019 13:15:44 -0700 [thread overview]
Message-ID: <20190523131544.6d8a28f7@hermes.lan> (raw)
In-Reply-To: <3dbe4e29bf1ec71809e9dd2b32ec16272957a4cd.camel@mellanox.com>
On Thu, 23 May 2019 19:19:40 +0000
Saeed Mahameed <saeedm@mellanox.com> wrote:
> On Thu, 2019-05-23 at 10:54 -0700, Stephen Hemminger wrote:
> > When a device is stacked like (team, bonding, failsafe or netvsc) the
> > XDP generic program for the parent device was not called.
> >
> > Move the call to XDP generic inside __netif_receive_skb_core where
> > it can be done multiple times for stacked case.
> >
> > Suggested-by: Jiri Pirko <jiri@resnulli.us>
> > Fixes: d445516966dc ("net: xdp: support xdp generic on virtual
> > devices")
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > ---
> > v1 - call xdp_generic in netvsc handler
> > v2 - do xdp_generic in generic rx handler processing
> > v3 - move xdp_generic call inside the another pass loop
> >
> > net/core/dev.c | 56 ++++++++++------------------------------------
> > ----
> > 1 file changed, 11 insertions(+), 45 deletions(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index b6b8505cfb3e..696776e14d00 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -4502,23 +4502,6 @@ static int netif_rx_internal(struct sk_buff
> > *skb)
> >
> > trace_netif_rx(skb);
> >
> > - if (static_branch_unlikely(&generic_xdp_needed_key)) {
> > - int ret;
> > -
> > - preempt_disable();
> > - rcu_read_lock();
> > - ret = do_xdp_generic(rcu_dereference(skb->dev-
> > >xdp_prog), skb);
> > - rcu_read_unlock();
> > - preempt_enable();
> > -
> > - /* Consider XDP consuming the packet a success from
> > - * the netdev point of view we do not want to count
> > - * this as an error.
> > - */
> > - if (ret != XDP_PASS)
> > - return NET_RX_SUCCESS;
> > - }
> > -
>
> Adding Jesper,
>
> There is a small behavioral change due to this patch,
> the XDP program after this patch will run on the RPS CPU, if
> configured, which could cause some behavioral changes in
> xdp_redirect_cpu: bpf_redirect_map(cpu_map).
>
> Maybe this is acceptable, but it should be documented, as the current
> assumption dictates: XDP program runs on the core where the XDP
> frame/SKB was first seen.
Or maybe XDP should just force off RPS (like it does gro)
next prev parent reply other threads:[~2019-05-23 20:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 17:54 [PATCH v3 0/2] XDP generic fixes Stephen Hemminger
2019-05-23 17:54 ` [PATCH v3 1/2] netvsc: unshare skb in VF rx handler Stephen Hemminger
2019-05-23 17:54 ` [PATCH v3 2/2] net: core: support XDP generic on stacked devices Stephen Hemminger
2019-05-23 19:19 ` Saeed Mahameed
2019-05-23 20:15 ` Stephen Hemminger [this message]
2019-05-24 9:33 ` Jesper Dangaard Brouer
2019-05-24 13:25 ` Jason Wang
2019-05-24 4:17 ` Jason Wang
2019-05-24 10:07 ` Jesper Dangaard Brouer
2019-05-24 13:06 ` Jason Wang
2019-05-27 4:29 ` David Miller
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=20190523131544.6d8a28f7@hermes.lan \
--to=stephen@networkplumber.org \
--cc=jesper.brouer@gmail.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=sthemmin@microsoft.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.