All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>,
	netdev@vger.kernel.org, Daniel Borkmann <borkmann@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Christoph Hellwig" <hch@infradead.org>,
	BjörnTöpel <bjorn.topel@intel.com>,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	makita.toshiaki@lab.ntt.co.jp
Subject: Re: [bpf-next V4 PATCH 3/8] xdp: add tracepoint for devmap like cpumap have
Date: Wed, 23 May 2018 07:24:03 -0700	[thread overview]
Message-ID: <4345d6a2-935d-e206-e309-b63825f880b8@gmail.com> (raw)
In-Reply-To: <152665048683.21055.2555532949856555388.stgit@firesoul>

On 05/18/2018 06:34 AM, Jesper Dangaard Brouer wrote:
> Notice how this allow us get XDP statistic without affecting the XDP
> performance, as tracepoint is no-longer activated on a per packet basis.
> 
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---


[...]

>  #include <trace/define_trace.h>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index cab72c100bb5..6f84100723b0 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -50,6 +50,7 @@
>  #include <linux/bpf.h>
>  #include <net/xdp.h>
>  #include <linux/filter.h>
> +#include <trace/events/xdp.h>
>  
>  #define DEV_CREATE_FLAG_MASK \
>  	(BPF_F_NUMA_NODE | BPF_F_RDONLY | BPF_F_WRONLY)
> @@ -57,6 +58,7 @@
>  #define DEV_MAP_BULK_SIZE 16
>  struct xdp_bulk_queue {
>  	struct xdp_frame *q[DEV_MAP_BULK_SIZE];
> +	struct net_device *dev_rx;
>  	unsigned int count;
>  };
>  
> @@ -219,8 +221,8 @@ void __dev_map_insert_ctx(struct bpf_map *map, u32 bit)
>  static int bq_xmit_all(struct bpf_dtab_netdev *obj,
>  			 struct xdp_bulk_queue *bq)
>  {
> -	unsigned int processed = 0, drops = 0;
>  	struct net_device *dev = obj->dev;
> +	int sent = 0, drops = 0;
>  	int i;
>  
>  	if (unlikely(!bq->count))
> @@ -241,10 +243,13 @@ static int bq_xmit_all(struct bpf_dtab_netdev *obj,
>  			drops++;
>  			xdp_return_frame(xdpf);
>  		}
> -		processed++;
> +		sent++;

Do 'dropped' frames also get counted as 'sent' frames? This seems a bit
counter-intuitive to me. Should it be 'drops+sent = total frames'
instead?

>  	}
>  	bq->count = 0;
>  
> +	trace_xdp_devmap_xmit(&obj->dtab->map, obj->bit,
> +			      sent, drops, bq->dev_rx, dev);
> +	bq->dev_rx = NULL;
>  	return 0;
>  }
>  
> @@ -301,18 +306,28 @@ struct bpf_dtab_netdev *__dev_map_lookup_elem(struct bpf_map *map, u32 key)
>  /* Runs under RCU-read-side, plus in softirq under NAPI protection.
>   * Thus, safe percpu variable access.
>   */
> -static int bq_enqueue(struct bpf_dtab_netdev *obj, struct xdp_frame *xdpf)
> +static int bq_enqueue(struct bpf_dtab_netdev *obj, struct xdp_frame *xdpf,
> +		      struct net_device *dev_rx)
> +
>  {
>  	struct xdp_bulk_queue *bq = this_cpu_ptr(obj->bulkq);
>  
>  	if (unlikely(bq->count == DEV_MAP_BULK_SIZE))
>  		bq_xmit_all(obj, bq);
>  
> +	/* Ingress dev_rx will be the same for all xdp_frame's in
> +	 * bulk_queue, because bq stored per-CPU and must be flushed
> +	 * from net_device drivers NAPI func end.
> +	 */
> +	if (!bq->dev_rx)
> +		bq->dev_rx = dev_rx;
> +
>  	bq->q[bq->count++] = xdpf;
>  	return 0;
>  }
>  
> -int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
> +int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp,
> +		    struct net_device *dev_rx)
>  {
>  	struct net_device *dev = dst->dev;
>  	struct xdp_frame *xdpf;
> @@ -325,7 +340,7 @@ int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
>  	if (unlikely(!xdpf))
>  		return -EOVERFLOW;
>  
> -	err = bq_enqueue(dst, xdpf);
> +	err = bq_enqueue(dst, xdpf, dev_rx);
>  	if (err)
>  		return err;
>  
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 1447ec94ef74..4a93423cc5ea 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -3063,7 +3063,7 @@ static int __bpf_tx_xdp_map(struct net_device *dev_rx, void *fwd,
>  	case BPF_MAP_TYPE_DEVMAP: {
>  		struct bpf_dtab_netdev *dst = fwd;
>  
> -		err = dev_map_enqueue(dst, xdp);
> +		err = dev_map_enqueue(dst, xdp, dev_rx);
>  		if (err)
>  			return err;
>  		__dev_map_insert_ctx(map, index);
> 

  reply	other threads:[~2018-05-23 14:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18 13:34 [bpf-next V4 PATCH 0/8] xdp: introduce bulking for ndo_xdp_xmit API Jesper Dangaard Brouer
2018-05-18 13:34 ` [bpf-next V4 PATCH 1/8] bpf: devmap introduce dev_map_enqueue Jesper Dangaard Brouer
2018-05-23  9:34   ` Daniel Borkmann
2018-05-23 11:12     ` Jesper Dangaard Brouer
2018-05-18 13:34 ` [bpf-next V4 PATCH 2/8] bpf: devmap prepare xdp frames for bulking Jesper Dangaard Brouer
2018-05-23  9:54   ` Daniel Borkmann
2018-05-23 10:29     ` Jesper Dangaard Brouer
2018-05-23 10:45       ` Daniel Borkmann
2018-05-23 10:38     ` Jesper Dangaard Brouer
2018-05-18 13:34 ` [bpf-next V4 PATCH 3/8] xdp: add tracepoint for devmap like cpumap have Jesper Dangaard Brouer
2018-05-23 14:24   ` John Fastabend [this message]
2018-05-23 15:04     ` Jesper Dangaard Brouer
2018-05-18 13:34 ` [bpf-next V4 PATCH 4/8] samples/bpf: xdp_monitor use tracepoint xdp:xdp_devmap_xmit Jesper Dangaard Brouer
2018-05-18 13:34 ` [bpf-next V4 PATCH 5/8] xdp: introduce xdp_return_frame_rx_napi Jesper Dangaard Brouer
2018-05-18 20:46   ` Jesper Dangaard Brouer
2018-05-18 13:35 ` [bpf-next V4 PATCH 6/8] xdp: change ndo_xdp_xmit API to support bulking Jesper Dangaard Brouer
2018-05-23 14:42   ` John Fastabend
2018-05-23 15:27     ` Jesper Dangaard Brouer
2018-05-18 13:35 ` [bpf-next V4 PATCH 7/8] xdp/trace: extend tracepoint in devmap with an err Jesper Dangaard Brouer
2018-05-18 20:49   ` Jesper Dangaard Brouer
2018-05-18 13:35 ` [bpf-next V4 PATCH 8/8] samples/bpf: xdp_monitor use err code from tracepoint xdp:xdp_devmap_xmit Jesper Dangaard Brouer
2018-05-18 20:48   ` Jesper Dangaard Brouer
2018-05-23  9:24 ` [bpf-next V4 PATCH 0/8] xdp: introduce bulking for ndo_xdp_xmit API Daniel Borkmann

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=4345d6a2-935d-e206-e309-b63825f880b8@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bjorn.topel@intel.com \
    --cc=borkmann@iogearbox.net \
    --cc=brouer@redhat.com \
    --cc=hch@infradead.org \
    --cc=magnus.karlsson@intel.com \
    --cc=makita.toshiaki@lab.ntt.co.jp \
    --cc=netdev@vger.kernel.org \
    /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.