From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Lorenz Bauer <lmb@cloudflare.com>
Cc: andrii@kernel.org, ast@kernel.org, daniel@iogearbox.net,
bpf@vger.kernel.org, kernel-team@cloudflare.com
Subject: Re: [RFC 9/9] libbpf: use new-style syscall args
Date: Wed, 20 Oct 2021 10:19:35 -0700 [thread overview]
Message-ID: <20211020171935.qsxfrhv2i5n3hkc7@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20211014143436.54470-13-lmb@cloudflare.com>
On Thu, Oct 14, 2021 at 03:34:36PM +0100, Lorenz Bauer wrote:
> ---
> tools/lib/bpf/bpf.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 7d1741ceaa32..79a9bfe214b0 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -506,15 +506,14 @@ int bpf_map_delete_elem(int fd, const void *key)
>
> int bpf_map_get_next_key(int fd, const void *key, void *next_key)
> {
> - union bpf_attr attr;
> - int ret;
> + struct bpf_map_get_next_key_attr attr = {
> + .map_fd = fd,
> + .key = key,
> + .next_key = next_key,
> + };
I see this change as the main advantage of additional uapi structs.
Note, though, that such stack savings don't strictly need uapi extensions.
Light skeleton already doing that.
Every command is using exactly the right amount of stack/bytes.
The full 'union bpf_attr' is never allocated.
Take a look at bpf_gen__map_freeze() in libbpf gen_loader.c.
In case of light skeleton it's not only the stack. Saving space
in loader's map was important.
prev parent reply other threads:[~2021-10-20 17:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 14:34 [RFC 0/9] uapi/bpf.h for robots Lorenz Bauer
2021-10-14 14:34 ` [RFC 1/9] bpf: name enums used from userspace Lorenz Bauer
2021-10-14 14:34 ` [RFC 2/9] bpf: various constants Lorenz Bauer
2021-10-14 14:43 ` Greg KH
2021-10-14 14:47 ` Lorenz Bauer
2021-10-14 14:56 ` Greg KH
2021-10-14 14:34 ` [RFC 3/9] bpf: move up __bpf_md_ptr Lorenz Bauer
2021-10-14 14:34 ` [RFC 4/9] bpf: name __u64 member of __bpf_md_ptr Lorenz Bauer
2021-10-14 14:34 ` [RFC 5/9] bpf: enum bpf_map_create_attr Lorenz Bauer
2021-10-14 14:34 ` [RFC 5/9] bpf: introduce CHECK_ATTR_TAIL Lorenz Bauer
2021-10-14 14:34 ` [RFC 6/9] bpf: split map modification structs Lorenz Bauer
2021-10-20 17:13 ` Alexei Starovoitov
2021-10-14 14:34 ` [RFC 6/9] bpf: struct bpf_map_create_attr Lorenz Bauer
2021-10-14 14:34 ` [RFC 7/9] bpf: split get_id and fd_by_id in bpf_attr Lorenz Bauer
2021-10-20 17:15 ` Alexei Starovoitov
2021-10-21 15:59 ` Lorenz Bauer
2021-10-27 18:20 ` Alexei Starovoitov
2021-10-29 14:01 ` Lorenz Bauer
2021-10-14 14:34 ` [RFC 7/9] bpf: split map modification structs Lorenz Bauer
2021-10-14 14:34 ` [RFC 8/9] selftests: sync bpf.h Lorenz Bauer
2021-10-14 14:34 ` [RFC 9/9] libbpf: use new-style syscall args Lorenz Bauer
2021-10-20 17:19 ` Alexei Starovoitov [this message]
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=20211020171935.qsxfrhv2i5n3hkc7@ast-mbp.dhcp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@cloudflare.com \
--cc=lmb@cloudflare.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;
as well as URLs for NNTP newsgroup(s).