BPF List
 help / color / mirror / Atom feed
From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, Yonghong Song <yhs@fb.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	bpf <bpf@vger.kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [PATCH RFC 1/6] bpf: Add BTF_KIND_FLOAT to uapi
Date: Thu, 11 Feb 2021 22:26:37 +0100	[thread overview]
Message-ID: <bda4c4eb4e9e01a6ecaf4e0cf14e265997520740.camel@linux.ibm.com> (raw)
In-Reply-To: <CAEf4BzY-SOyP0g-ZHTK3h1mppwRGJ4YH3vKugeuLGTe8Q3-r7Q@mail.gmail.com>

On Wed, 2021-02-10 at 16:19 -0800, Andrii Nakryiko wrote:
> On Tue, Feb 9, 2021 at 7:03 PM Ilya Leoshkevich <iii@linux.ibm.com>
> wrote:
> > 
> > Add a new kind value, expand the kind bitfield, add a macro for
> > parsing the additional u32.
> > 
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> >  include/uapi/linux/btf.h       | 10 ++++++++--
> >  tools/include/uapi/linux/btf.h | 10 ++++++++--
> >  2 files changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
> > index 5a667107ad2c..e713430cb033 100644
> > --- a/include/uapi/linux/btf.h
> > +++ b/include/uapi/linux/btf.h
> > @@ -52,7 +52,7 @@ struct btf_type {
> >         };
> >  };
> > 
> > -#define BTF_INFO_KIND(info)    (((info) >> 24) & 0x0f)
> > +#define BTF_INFO_KIND(info)    (((info) >> 24) & 0x1f)
> >  #define BTF_INFO_VLEN(info)    ((info) & 0xffff)
> >  #define BTF_INFO_KFLAG(info)   ((info) >> 31)
> > 
> > @@ -72,7 +72,8 @@ struct btf_type {
> >  #define BTF_KIND_FUNC_PROTO    13      /* Function Proto       */
> >  #define BTF_KIND_VAR           14      /* Variable     */
> >  #define BTF_KIND_DATASEC       15      /* Section      */
> > -#define BTF_KIND_MAX           BTF_KIND_DATASEC
> > +#define BTF_KIND_FLOAT         16      /* Floating point       */
> > +#define BTF_KIND_MAX           BTF_KIND_FLOAT
> >  #define NR_BTF_KINDS           (BTF_KIND_MAX + 1)
> > 
> >  /* For some specific BTF_KIND, "struct btf_type" is immediately
> > @@ -169,4 +170,9 @@ struct btf_var_secinfo {
> >         __u32   size;
> >  };
> > 
> > +/* BTF_KIND_FLOAT is followed by a u32 and the following
> 
> 
> what's the point of that u32, if BTF_FLOAT_BITS() is just t->size *
> 8?
> Why adding this complexity. BTF_KIND_INT has bits because we had an
> inconvenient bitfield encoding as a special BTF_KIND_INT types, which
> we since stopped using in favor of encoding bitfield sizes and
> offsets
> inside struct/union fields. I don't think there is any need for that
> with FLOAT, so why waste space and add complexity and possibility for
> inconsistencies?

You are right, this is not necessary. I don't think something like a
floating-point bitfield exists in the first place.

> Disclaimer: I'm in a "just BTF_KIND_INT encoding bit for
> floating-point numbers" camp.

Despite me being the guy, who sent this series, I like such a simpler
approach as well. In fact, my first attempt at this was even simpler -
just a char[] - but this didn't let us distinguish floats from "real"
byte arrays, which BTF_KIND_INT encoding does. But I think we need to
convince Alexey that this would be OK? :-) If that helps, I can
implement the BTF_KIND_INT encoding variant, so that we could compare
both approaches. What do you think?

> > + * is the 32 bits arrangement:
> > + */
> > +#define BTF_FLOAT_BITS(VAL)    ((VAL)  & 0x000000ff)
> > +
> >  #endif /* _UAPI__LINUX_BTF_H__ */
> > diff --git a/tools/include/uapi/linux/btf.h
> > b/tools/include/uapi/linux/btf.h
> > index 5a667107ad2c..e713430cb033 100644
> > --- a/tools/include/uapi/linux/btf.h
> > +++ b/tools/include/uapi/linux/btf.h
> > @@ -52,7 +52,7 @@ struct btf_type {
> >         };
> >  };
> > 
> > -#define BTF_INFO_KIND(info)    (((info) >> 24) & 0x0f)
> > +#define BTF_INFO_KIND(info)    (((info) >> 24) & 0x1f)
> >  #define BTF_INFO_VLEN(info)    ((info) & 0xffff)
> >  #define BTF_INFO_KFLAG(info)   ((info) >> 31)
> > 
> > @@ -72,7 +72,8 @@ struct btf_type {
> >  #define BTF_KIND_FUNC_PROTO    13      /* Function Proto       */
> >  #define BTF_KIND_VAR           14      /* Variable     */
> >  #define BTF_KIND_DATASEC       15      /* Section      */
> > -#define BTF_KIND_MAX           BTF_KIND_DATASEC
> > +#define BTF_KIND_FLOAT         16      /* Floating point       */
> > +#define BTF_KIND_MAX           BTF_KIND_FLOAT
> >  #define NR_BTF_KINDS           (BTF_KIND_MAX + 1)
> > 
> >  /* For some specific BTF_KIND, "struct btf_type" is immediately
> > @@ -169,4 +170,9 @@ struct btf_var_secinfo {
> >         __u32   size;
> >  };
> > 
> > +/* BTF_KIND_FLOAT is followed by a u32 and the following
> > + * is the 32 bits arrangement:
> > + */
> > +#define BTF_FLOAT_BITS(VAL)    ((VAL)  & 0x000000ff)
> > +
> >  #endif /* _UAPI__LINUX_BTF_H__ */
> > --
> > 2.29.2
> > 



  reply	other threads:[~2021-02-11 21:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  3:03 [PATCH RFC 0/6] Add BTF_KIND_FLOAT support Ilya Leoshkevich
2021-02-10  3:03 ` [PATCH RFC 1/6] bpf: Add BTF_KIND_FLOAT to uapi Ilya Leoshkevich
2021-02-11  0:19   ` Andrii Nakryiko
2021-02-11 21:26     ` Ilya Leoshkevich [this message]
2021-02-11 23:11       ` Alexei Starovoitov
2021-02-10  3:03 ` [PATCH RFC 2/6] libbpf: Add BTF_KIND_FLOAT support Ilya Leoshkevich
2021-02-11  0:15   ` Andrii Nakryiko
2021-02-10  3:03 ` [PATCH RFC 3/6] tools/bpftool: " Ilya Leoshkevich
2021-02-10  3:03 ` [PATCH RFC 4/6] bpf: " Ilya Leoshkevich
2021-02-11  0:20   ` Andrii Nakryiko
2021-02-10  3:03 ` [PATCH RFC 5/6] selftest/bpf: Add BTF_KIND_FLOAT tests Ilya Leoshkevich
2021-02-10  3:03 ` [PATCH RFC 6/6] bpf: Document BTF_KIND_FLOAT in btf.rst Ilya Leoshkevich
2021-02-11  1:31 ` [PATCH RFC 0/6] Add BTF_KIND_FLOAT support Andrii Nakryiko

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=bda4c4eb4e9e01a6ecaf4e0cf14e265997520740.camel@linux.ibm.com \
    --to=iii@linux.ibm.com \
    --cc=acme@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox