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);
>
next prev parent 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$(echo .)com \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=bjorn.topel@intel$(echo .)com \
--cc=borkmann@iogearbox$(echo .)net \
--cc=brouer@redhat$(echo .)com \
--cc=hch@infradead$(echo .)org \
--cc=magnus.karlsson@intel$(echo .)com \
--cc=makita.toshiaki@lab$(echo .)ntt.co.jp \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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