netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeedm@mellanox.com>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	"jesper.brouer@gmail.com" <jesper.brouer@gmail.com>
Cc: "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 19:19:40 +0000	[thread overview]
Message-ID: <3dbe4e29bf1ec71809e9dd2b32ec16272957a4cd.camel@mellanox.com> (raw)
In-Reply-To: <20190523175429.13302-3-sthemmin@microsoft.com>

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.

>  #ifdef CONFIG_RPS
>  	if (static_branch_unlikely(&rps_needed)) {
>  		struct rps_dev_flow voidflow, *rflow = &voidflow;
> @@ -4858,6 +4841,17 @@ static int __netif_receive_skb_core(struct
> sk_buff *skb, bool pfmemalloc,
>  
>  	__this_cpu_inc(softnet_data.processed);
>  
> +	if (static_branch_unlikely(&generic_xdp_needed_key)) {
> +		int ret2;
> +
> +		preempt_disable();
> +		ret2 = do_xdp_generic(rcu_dereference(skb->dev-
> >xdp_prog), skb);
> +		preempt_enable();
> +
> +		if (ret2 != XDP_PASS)
> +			return NET_RX_DROP;
> +	}
> +
>  	if (skb->protocol == cpu_to_be16(ETH_P_8021Q) ||
>  	    skb->protocol == cpu_to_be16(ETH_P_8021AD)) {
>  		skb = skb_vlan_untag(skb);
> @@ -5178,19 +5172,6 @@ static int netif_receive_skb_internal(struct
> sk_buff *skb)
>  	if (skb_defer_rx_timestamp(skb))
>  		return NET_RX_SUCCESS;
>  
> -	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();
> -
> -		if (ret != XDP_PASS)
> -			return NET_RX_DROP;
> -	}
> -
>  	rcu_read_lock();
>  #ifdef CONFIG_RPS
>  	if (static_branch_unlikely(&rps_needed)) {
> @@ -5224,21 +5205,6 @@ static void
> netif_receive_skb_list_internal(struct list_head *head)
>  	}
>  	list_splice_init(&sublist, head);
>  
> -	if (static_branch_unlikely(&generic_xdp_needed_key)) {
> -		preempt_disable();
> -		rcu_read_lock();
> -		list_for_each_entry_safe(skb, next, head, list) {
> -			xdp_prog = rcu_dereference(skb->dev->xdp_prog);
> -			skb_list_del_init(skb);
> -			if (do_xdp_generic(xdp_prog, skb) == XDP_PASS)
> -				list_add_tail(&skb->list, &sublist);
> -		}
> -		rcu_read_unlock();
> -		preempt_enable();
> -		/* Put passed packets back on main list */
> -		list_splice_init(&sublist, head);
> -	}
> -
>  	rcu_read_lock();
>  #ifdef CONFIG_RPS
>  	if (static_branch_unlikely(&rps_needed)) {

  reply	other threads:[~2019-05-23 19:41 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 [this message]
2019-05-23 20:15     ` Stephen Hemminger
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=3dbe4e29bf1ec71809e9dd2b32ec16272957a4cd.camel@mellanox.com \
    --to=saeedm@mellanox.com \
    --cc=jesper.brouer@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).