All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: David Ahern <dsahern@kernel.org>,
	netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	toke@redhat.com, daniel@iogearbox.net, john.fastabend@gmail.com,
	ast@kernel.org, kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
	andriin@fb.com
Subject: Re: [PATCH bpf-next 1/5] bpf: Handle 8-byte values in DEVMAP and DEVMAP_HASH
Date: Wed, 27 May 2020 12:38:10 -0600	[thread overview]
Message-ID: <9e80e899-7b34-5901-abb1-a6daefcce3c7@gmail.com> (raw)
In-Reply-To: <20200527173021.10468d8b@carbon>

On 5/27/20 9:30 AM, Jesper Dangaard Brouer wrote:
> On Wed, 27 May 2020 08:27:36 -0600
> David Ahern <dsahern@gmail.com> wrote:
> 
>> On 5/27/20 4:26 AM, Jesper Dangaard Brouer wrote:
>>> 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".  
>>
>> furthermore, the kernel is changing the value - an fd is passed in and
>> an id is returned. I do not see how any of this fits into BTF.
> 
> It can, as BTF actually support union's (I just tested that).
> 

You are trying to force an arbitrary kernel API with BTF, and it adds no
value over a static struct definition that grows as new capability is added.

DEVMAPs (and CPUMAP) are not like other maps - the fields in the entries
have meaning to *the kernel*. That means the kernel needs to know the
fields and what they represent - be it a device index, a program fd
converted to an id, a cpuid, or any future extension. If you add 'u32
foo' to this interface, you still need kernel code to understand 'foo'
maps to resource 'bar' via lookup function 'f'. You can not do this
dynamically. BTF does not make sense here.

Furthermore, if the kernel does not understand a field then it better
return an error code - EINVAL so the user knows expected functionality
is not supported by that kernel.

> 
> But a union would also work (also tested via BPF loading and BTF dumpinmg):
> 
>  struct dev_map_ext_val {
>         u32 ifindex;
>         union {
>                 int bpf_prog_fd_write;
>                 u32 bpf_prog_id_read;
>         };
>  };
> 

I prefer the union and without the verb; comments convey the same
meaning. The fd has no meaning beyond the process that created the entry
so it does not need to be kept around bloating the interface.

For v2, I moved the struct to uapi/linux/bpf.h and added comments.

  reply	other threads:[~2020-05-27 18:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  1:09 [PATCH bpf-next 0/5] bpf: Add support for XDP programs in DEVMAP entries David Ahern
2020-05-27  1:09 ` [PATCH bpf-next 1/5] bpf: Handle 8-byte values in DEVMAP and DEVMAP_HASH David Ahern
2020-05-27 10:26   ` Jesper Dangaard Brouer
2020-05-27 13:56     ` David Ahern
2020-05-27 14:57       ` Toke Høiland-Jørgensen
2020-05-27 15:24         ` David Ahern
2020-05-27 14:27     ` David Ahern
2020-05-27 15:30       ` Jesper Dangaard Brouer
2020-05-27 18:38         ` David Ahern [this message]
2020-05-27  1:09 ` [PATCH bpf-next 2/5] bpf: Add support to attach bpf program to a devmap entry David Ahern
2020-05-27 10:01   ` Toke Høiland-Jørgensen
2020-05-27 14:02     ` David Ahern
2020-05-27 14:58       ` Toke Høiland-Jørgensen
2020-05-27  1:09 ` [PATCH bpf-next 3/5] xdp: Add xdp_txq_info to xdp_buff David Ahern
2020-05-27  1:09 ` [PATCH bpf-next 4/5] bpftool: Add SEC name for xdp programs attached to device map David Ahern
2020-05-27 10:02   ` Toke Høiland-Jørgensen
2020-05-27 14:03     ` David Ahern
2020-05-27 15:01       ` Toke Høiland-Jørgensen
2020-05-27 15:43         ` Jesper Dangaard Brouer
2020-05-27  1:09 ` [PATCH bpf-next 5/5] selftest: Add tests for XDP programs in devmap entries David Ahern

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=9e80e899-7b34-5901-abb1-a6daefcce3c7@gmail.com \
    --to=dsahern@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=toke@redhat.com \
    --cc=yhs@fb.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.