All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"KP Singh" <kpsingh@kernel.org>,
	"Stanislav Fomichev" <sdf@fomichev.me>,
	"Hao Luo" <haoluo@google.com>, "Jiri Olsa" <jolsa@kernel.org>,
	"Puranjay Mohan" <puranjay@kernel.org>,
	"Xu Kuohai" <xukuohai@huaweicloud.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Mykola Lysenko" <mykolal@fb.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Florent Revest" <revest@chromium.org>,
	"Bastien Curutchet" <bastien.curutchet@bootlin.com>,
	<ebpf@linuxfoundation.org>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	<bpf@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kselftest@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH RFC bpf-next 1/4] bpf: add struct largest member size in func model
Date: Wed, 23 Apr 2025 21:24:34 +0200	[thread overview]
Message-ID: <D9E9IQQ3QKXM.3UJ17G9CBS1FH@bootlin.com> (raw)
In-Reply-To: <CAEf4BzZHMYyGDZ4c4eNXG7Fm=ecxCCbKhKbQTbCjvWmKtdwvBw@mail.gmail.com>

Hi Andrii,

On Wed Apr 23, 2025 at 7:15 PM CEST, Andrii Nakryiko wrote:
> On Thu, Apr 17, 2025 at 12:14 AM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:
>>
>> Hi Andrii,
>>
>> On Wed Apr 16, 2025 at 11:24 PM CEST, Andrii Nakryiko wrote:
>> > On Fri, Apr 11, 2025 at 1:32 PM Alexis Lothoré (eBPF Foundation)
>> > <alexis.lothore@bootlin.com> wrote:

[...]

>> Indeed I initially checked whether I could return directly some alignment
>> info from btf, but it then involves the alignment computation in the btf
>> module. Since there could be minor differences between architectures about
>> alignment requirements, I though it would be better to in fact keep alignment
>> computation out of the btf module. For example, I see that 128 bits values
>> are aligned on 16 bytes on ARM64, while being aligned on 8 bytes on S390.
>>
>> And since for ARM64, all needed alignments are somehow derived from size
>> (it is either directly size for fundamental types, or alignment of the
>> largest member for structs, which is then size of largest member),
>> returning the size seems to be enough to allow the JIT side to compute
>> alignments.
>
> If you mean the size of "primitive" field and/or array element
> (applied recursively for all embedded structs/unions) then yes, that's
> close enough. But saying just "largest struct member" is wrong,
> because for
>
> struct blah {
>     struct {
>         int whatever[128];
>     } heya;
> };
>
>
> blah.heya has a large size, but alignment is still just 4 bytes.

Indeed, that's another case making my proposal fail :)

> I'd suggest looking at btf__align_of() in libbpf (tools/lib/bpf/btf.c)
> to see how we calculate alignment there. It seems to work decently
> enough. It won't cover any arch-specific extra rules like double
> needing 16-byte alignment (I vaguely remember something like that for
> some architectures, but I might be misremembering), or anything
> similar. It also won't detect (I don't think it's possible without
> DWARF) artificially increased alignment with attribute((aligned(N))).

Thanks for the pointer, I'll take a look at it. The more we discuss this
series, the less member size sounds relevant for what I'm trying to achieve
here.

Following Xu's comments, I have been thinking about how I could detect the
custom alignments and packing on structures, and I was wondering if I could
somehow benefit from __attribute__ encoding in BTF info ([1]). But
following your hint, I also see some btf_is_struct_packed() in
tools/lib/bpf/btf_dump.c that could help. I'll dig this further and see if
I can manage to make something work with all of this.

Thanks,

Alexis

[1] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev/

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2025-04-23 19:24 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 20:32 [PATCH RFC bpf-next 0/4] bpf, arm64: support up to 12 arguments Alexis Lothoré (eBPF Foundation)
2025-04-11 20:32 ` [PATCH RFC bpf-next 1/4] bpf: add struct largest member size in func model Alexis Lothoré (eBPF Foundation)
2025-04-14 11:04   ` Jiri Olsa
2025-04-14 20:27     ` Alexis Lothoré
2025-04-16 21:24   ` Andrii Nakryiko
2025-04-17  7:14     ` Alexis Lothoré
2025-04-17 14:10       ` Xu Kuohai
2025-04-20 16:02         ` Alexis Lothoré
2025-04-21  2:14           ` Xu Kuohai
2025-04-23 15:38             ` Alexis Lothoré
2025-04-23 17:15       ` Andrii Nakryiko
2025-04-23 19:24         ` Alexis Lothoré [this message]
2025-04-24 12:00           ` Xu Kuohai
2025-04-24 13:38             ` Alexis Lothoré
2025-04-24 23:14               ` Alexei Starovoitov
2025-04-25  8:47                 ` Alexis Lothoré
2025-04-25  9:23               ` Xu Kuohai
2025-04-28  7:11                 ` Eduard Zingerman
2025-06-04  9:02           ` [Question] attributes encoding in BTF Alexis Lothoré
2025-06-04 17:31             ` Ihor Solodrai
2025-06-05  7:35               ` Alexis Lothoré
2025-06-05 16:09                 ` Alexei Starovoitov
2025-06-06  7:45                   ` Alexis Lothoré
2025-06-06 16:22                     ` Alexei Starovoitov
2025-04-11 20:32 ` [PATCH RFC bpf-next 2/4] bpf, arm64: Support up to 12 function arguments Alexis Lothoré
2025-04-11 20:32 ` [PATCH RFC bpf-next 3/4] bpf/selftests: add tests to validate proper arguments alignment on ARM64 Alexis Lothoré (eBPF Foundation)
2025-04-28  7:01   ` Eduard Zingerman
2025-04-28 10:08     ` Alexis Lothoré
2025-04-28 16:52       ` Eduard Zingerman
2025-04-28 20:41         ` Alexis Lothoré
2025-04-29  9:49           ` Alexis Lothoré
2025-04-11 20:32 ` [PATCH RFC bpf-next 4/4] bpf/selftests: enable tracing tests for ARM64 Alexis Lothoré (eBPF Foundation)

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=D9E9IQQ3QKXM.3UJ17G9CBS1FH@bootlin.com \
    --to=alexis.lothore@bootlin.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bastien.curutchet@bootlin.com \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=ebpf@linuxfoundation.org \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=martin.lau@linux.dev \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mykolal@fb.com \
    --cc=puranjay@kernel.org \
    --cc=revest@chromium.org \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=will@kernel.org \
    --cc=xukuohai@huaweicloud.com \
    --cc=yonghong.song@linux.dev \
    /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.