[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200527122612.579fbb25@carbon>
Date: Wed, 27 May 2020 12:26:12 +0200
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: David Ahern <dsahern@...nel.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
toke@...hat.com, daniel@...earbox.net, john.fastabend@...il.com,
ast@...nel.org, kafai@...com, songliubraving@...com, yhs@...com,
andriin@...com, dsahern@...il.com, brouer@...hat.com
Subject: Re: [PATCH bpf-next 1/5] bpf: Handle 8-byte values in DEVMAP and
DEVMAP_HASH
On Tue, 26 May 2020 19:09:01 -0600
David Ahern <dsahern@...nel.org> wrote:
> Add support to DEVMAP and DEVMAP_HASH to support 8-byte values as a
> <device index, program id> pair. To do this, a new struct is needed in
> bpf_dtab_netdev to hold the values to return on lookup.
>
> Signed-off-by: David Ahern <dsahern@...nel.org>
> ---
> kernel/bpf/devmap.c | 56 ++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index a51d9fb7a359..95db6d8beebc 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -60,12 +60,22 @@ struct xdp_dev_bulk_queue {
> unsigned int count;
> };
>
> +/* devmap value can be dev index or dev index + prog fd/id */
> +struct dev_map_ext_val {
> + u32 ifindex; /* must be first for compat with 4-byte values */
> + union {
> + int prog_fd; /* prog fd on write */
> + u32 prog_id; /* prog id on read */
> + };
> +};
This smells like a BTF structure.
Andrii BTF does support union's right?
> struct bpf_dtab_netdev {
> struct net_device *dev; /* must be first member, due to tracepoint */
> struct hlist_node index_hlist;
> struct bpf_dtab *dtab;
> struct rcu_head rcu;
> unsigned int idx;
> + struct dev_map_ext_val val;
> };
>
> struct bpf_dtab {
> @@ -108,9 +118,13 @@ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
> u64 cost = 0;
> int err;
>
> - /* check sanity of attributes */
> + /* check sanity of attributes. 2 value sizes supported:
> + * 4 bytes: ifindex
> + * 8 bytes: ifindex + prog fd
> + */
> if (attr->max_entries == 0 || attr->key_size != 4 ||
> - attr->value_size != 4 || attr->map_flags & ~DEV_CREATE_FLAG_MASK)
> + (attr->value_size != 4 && attr->value_size != 8) ||
IMHO we really need to leverage BTF here, as I'm sure we need to do more
extensions, and this size matching will get more and more unmaintainable.
With BTF in place, dumping the map via bpftool, will also make the
fields "self-documenting".
I will try to implement something that uses BTF for this case (and cpumap).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists