All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.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>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	brouer@redhat.com
Subject: Re: [PATCH v5 bpf-next 7/9] xdp: Helpers for disabling napi_direct of xdp_return_frame
Date: Mon, 30 Jul 2018 14:33:49 +0200	[thread overview]
Message-ID: <20180730143349.795de127@redhat.com> (raw)
In-Reply-To: <20180726144032.2116-8-toshiaki.makita1@gmail.com>

On Thu, 26 Jul 2018 23:40:30 +0900
Toshiaki Makita <toshiaki.makita1@gmail.com> wrote:

> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> 
> We need some mechanism to disable napi_direct on calling
> xdp_return_frame_rx_napi() from some context.
> When veth gets support of XDP_REDIRECT, it will redirects packets which
> are redirected from other devices. On redirection veth will reuse
> xdp_mem_info of the redirection source device to make return_frame work.
> But in this case .ndo_xdp_xmit() called from veth redirection uses
> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit()
> is not called directly from the rxq which owns the xdp_mem_info.

Hmm "not guarded by NAPI" sounds scary to me, as XDP depends heavily on
being protected by NAPI. But it does look like you handle this is
earlier patches...

> This approach introduces a flag in bpf_redirect_info to indicate that
> napi_direct should be disabled even when _rx_napi variant is used as
> well as helper functions to use it.
> 
> A NAPI handler who wants to use this flag needs to call
> xdp_set_return_frame_no_direct() before processing packets, and call
> xdp_clear_return_frame_no_direct() after xdp_do_flush_map() before
> exiting NAPI.

Okay, so it still runs under NAPI. It should be okay then.  Also such
that the bpf_redirect_info is "stable", in the sense that we cannot
change the CPU we are running on, given bpf_redirect_info is a per-cpu thing.

> v4:
> - Use bpf_redirect_info for storing the flag instead of xdp_mem_info to
>   avoid per-frame copy cost.
> 
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
>  include/linux/filter.h | 25 +++++++++++++++++++++++++
>  net/core/xdp.c         |  6 ++++--
>  2 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 4717af8b95e6..2b072dab32c0 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -543,10 +543,14 @@ struct bpf_redirect_info {
>  	struct bpf_map *map;
>  	struct bpf_map *map_to_flush;
>  	unsigned long   map_owner;
> +	u32 kern_flags;
>  };
>  
>  DECLARE_PER_CPU(struct bpf_redirect_info, bpf_redirect_info);
>  
> +/* flags for bpf_redirect_info kern_flags */
> +#define BPF_RI_F_RF_NO_DIRECT	BIT(0)	/* no napi_direct on return_frame */
> +
>  /* Compute the linear packet data range [data, data_end) which
>   * will be accessed by various program types (cls_bpf, act_bpf,
>   * lwt, ...). Subsystems allowing direct data access must (!)
> @@ -775,6 +779,27 @@ static inline bool bpf_dump_raw_ok(void)
>  struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off,
>  				       const struct bpf_insn *patch, u32 len);
>  
> +static inline bool xdp_return_frame_no_direct(void)
> +{
> +	struct bpf_redirect_info *ri = this_cpu_ptr(&bpf_redirect_info);
> +
> +	return ri->kern_flags & BPF_RI_F_RF_NO_DIRECT;
> +}
> +
> +static inline void xdp_set_return_frame_no_direct(void)
> +{
> +	struct bpf_redirect_info *ri = this_cpu_ptr(&bpf_redirect_info);
> +
> +	ri->kern_flags |= BPF_RI_F_RF_NO_DIRECT;
> +}
> +
> +static inline void xdp_clear_return_frame_no_direct(void)
> +{
> +	struct bpf_redirect_info *ri = this_cpu_ptr(&bpf_redirect_info);
> +
> +	ri->kern_flags &= ~BPF_RI_F_RF_NO_DIRECT;
> +}
> +
>  static inline int xdp_ok_fwd_dev(const struct net_device *fwd,
>  				 unsigned int pktlen)
>  {
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 57285383ed00..3dd99e1c04f5 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -330,10 +330,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
>  		/* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
>  		xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
>  		page = virt_to_head_page(data);
> -		if (xa)
> +		if (xa) {
> +			napi_direct &= !xdp_return_frame_no_direct();
>  			page_pool_put_page(xa->page_pool, page, napi_direct);
> -		else
> +		} else {
>  			put_page(page);
> +		}
>  		rcu_read_unlock();
>  		break;
>  	case MEM_TYPE_PAGE_SHARED:



-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2018-07-30 14:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26 14:40 [PATCH v5 bpf-next 0/9] veth: Driver XDP Toshiaki Makita
2018-07-26 14:40 ` [PATCH v5 bpf-next 1/9] net: Export skb_headers_offset_update Toshiaki Makita
2018-07-26 14:40 ` [PATCH v5 bpf-next 2/9] veth: Add driver XDP Toshiaki Makita
2018-07-27  3:02   ` John Fastabend
2018-07-27  4:55     ` Toshiaki Makita
2018-07-26 14:40 ` [PATCH v5 bpf-next 3/9] veth: Avoid drops by oversized packets when XDP is enabled Toshiaki Makita
2018-07-27  0:51   ` Jakub Kicinski
2018-07-27  1:06     ` Toshiaki Makita
2018-07-27  1:08       ` Jakub Kicinski
2018-07-26 14:40 ` [PATCH v5 bpf-next 4/9] veth: Handle xdp_frames in xdp napi ring Toshiaki Makita
2018-07-27  3:40   ` John Fastabend
2018-07-26 14:40 ` [PATCH v5 bpf-next 5/9] veth: Add ndo_xdp_xmit Toshiaki Makita
2018-07-27  3:54   ` John Fastabend
2018-07-26 14:40 ` [PATCH v5 bpf-next 6/9] bpf: Make redirect_info accessible from modules Toshiaki Makita
2018-07-29  7:06   ` kbuild test robot
2018-07-26 14:40 ` [PATCH v5 bpf-next 7/9] xdp: Helpers for disabling napi_direct of xdp_return_frame Toshiaki Makita
2018-07-30 12:33   ` Jesper Dangaard Brouer [this message]
2018-07-26 14:40 ` [PATCH v5 bpf-next 8/9] veth: Add XDP TX and REDIRECT Toshiaki Makita
2018-07-26 14:40 ` [PATCH v5 bpf-next 9/9] 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=20180730143349.795de127@redhat.com \
    --to=brouer@redhat.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jakub.kicinski@netronome.com \
    --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.