From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Tom Herbert <tom@herbertland.com>
Cc: brouer@redhat.com, <netdev@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP
Date: Tue, 14 Feb 2017 21:31:57 +0100 [thread overview]
Message-ID: <20170214213157.32e37148@redhat.com> (raw)
In-Reply-To: <20170208234127.3041579-2-tom@herbertland.com>
On Wed, 8 Feb 2017 15:41:20 -0800
Tom Herbert <tom@herbertland.com> wrote:
> +static inline int __xdp_run_one_hook(struct xdp_hook *hook,
> + struct xdp_buff *xdp)
> +{
> + void *priv = rcu_dereference(hook->priv);
> +
> + if (hook->is_bpf) {
> + /* Run BPF programs directly do avoid one layer of
> + * indirection.
> + */
> + return BPF_PROG_RUN((struct bpf_prog *)priv, (void *)xdp);
> + } else {
> + return hook->hookfn(priv, xdp);
> + }
> +}
> +
> +/* Core function to run the XDP hooks. This must be as fast as possible */
> +static inline int __xdp_hook_run(struct xdp_hook_set *hook_set,
> + struct xdp_buff *xdp,
> + struct xdp_hook **last_hook)
> +{
> + struct xdp_hook *hook;
> + int i, ret;
> +
> + if (unlikely(!hook_set))
> + return XDP_PASS;
> +
> + hook = &hook_set->hooks[0];
> + ret = __xdp_run_one_hook(hook, xdp);
> + *last_hook = hook;
> +
> + for (i = 1; i < hook_set->num; i++) {
> + if (ret != XDP_PASS)
> + break;
> + hook = &hook_set->hooks[i];
> + ret = __xdp_run_one_hook(hook, xdp);
> + }
> +
> + return ret;
> +}
There is one basic problem with this approach. There is no bulking and
no reuse of instruction cache. There is no revolution in this approach.
We will end-up with the same known performance problems when more hook
users get added.
Calling N-number of hooks per every packet, will just end-up flushing
the instruction cache (like the issues we have today).
Instead take N-packets, and then call the hooks by turn (store action
verdicts in packet-vector). Such an architecture would be inline with
that VPP, Snabb and DPDK is doing. Optimizing icache usage, and opens
up for smarter prefetching of lookup tables. Imagine, having hook-1
identify lookup bucket and start prefetch, hook-2 access the bucket and
prefetch table data, and hook-3 read data. This is what DPDK is doing
see[1], and VPP is doing similar tricks to get it to scale to large
route lookup tables.
[1] http://dpdk.org/doc/guides/prog_guide/packet_framework.html#figure-figure35
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2017-02-14 20:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-08 23:41 [PATCH RFC v2 0/8] xdp: Generalize XDP Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP Tom Herbert
2017-02-09 7:49 ` Jiri Pirko
2017-02-09 14:22 ` Mintz, Yuval
2017-02-09 22:17 ` David Miller
2017-02-09 22:26 ` Tom Herbert
2017-02-09 22:34 ` David Miller
2017-02-09 22:45 ` Tom Herbert
2017-02-10 1:42 ` David Miller
2017-02-10 2:29 ` Tom Herbert
2017-02-10 3:33 ` David Miller
2017-02-10 4:55 ` Tom Herbert
2017-02-10 15:12 ` David Miller
2017-02-09 23:08 ` Tom Herbert
2017-02-10 1:48 ` David Miller
2017-02-10 2:30 ` Tom Herbert
2017-02-10 5:42 ` Jason Wang
2017-02-13 2:41 ` [lkp-robot] [xdp] 543d41bf78: INFO:suspicious_RCU_usage kernel test robot
2017-02-13 2:41 ` kernel test robot
2017-02-14 20:31 ` Jesper Dangaard Brouer [this message]
2017-02-14 20:47 ` [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP Tom Herbert
2017-02-14 21:07 ` Tom Herbert
2017-02-14 22:08 ` Edward Cree
2017-02-14 22:28 ` Tom Herbert
2017-02-14 22:29 ` Jesper Dangaard Brouer
2017-02-08 23:41 ` [PATCH RFC v2 2/8] mlx4: Changes to use generic XDP infrastructure Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 3/8] nfp: " Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 4/8] qede: " Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 5/8] virt_net: " Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 6/8] mlx5: " Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 7/8] bnxt: " Tom Herbert
2017-02-08 23:41 ` [PATCH RFC v2 8/8] xdp: Cleanup after API changes Tom Herbert
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=20170214213157.32e37148@redhat.com \
--to=brouer@redhat.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.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.