From: Martin KaFai Lau <martin.lau@linux.dev>
To: Amery Hung <ameryhung@gmail.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>, Tejun Heo <tj@kernel.org>,
Martin KaFai Lau <martin.lau@kernel.org>,
Kernel Team <kernel-team@meta.com>, bpf <bpf@vger.kernel.org>
Subject: Re: [RFC bpf-next v1 2/4] bpf: Support cookie for linked-based struct_ops attachment
Date: Mon, 14 Jul 2025 15:51:19 -0700 [thread overview]
Message-ID: <2fe9d096-846c-4cb6-ac7e-a9e072cb3281@linux.dev> (raw)
In-Reply-To: <CAMB2axNXLm2mWnSv4EL_YxexYa97_OnRD9Nj7ww9Qq_3dAp5hg@mail.gmail.com>
On 7/14/25 2:02 PM, Amery Hung wrote:
>>> It should work. Currently, it makes sense to have cookie in struct_ops
>>> map as all struct_ops implementers (hid, tcp cc, qdisc, sched_ext) do
>>> not allow multi-attachment of the same map. A struct_ops map is
>>> effectively an unique attachment for now.
>>
>> Is there any conceptual reason why struct_ops map shouldn't be allowed
>> to be attached to multiple places? If not, should we try to lift this
>> restriction and not invent struct_ops-specific BPF cookie APIs?
bpf_struct_ops map currently does allow attaching multiple times through the
link interface. It is up to the subsystem tcp-cc/hid/qdisc/scx how to handle it.
> I am fixing the patchset by moving trampoline and ksyms to
> bpf_struct_ops_link. It shouldn't complicate struct_ops code too much
> (finger cross).
seems reasonable. I think it will be useful to have comments in v2 on how their
lifecycle will be handled.
next prev parent reply other threads:[~2025-07-14 22:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 23:08 [RFC bpf-next v1 0/4] Support cookie for link-based struct_ops attachment Amery Hung
2025-07-08 23:08 ` [RFC bpf-next v1 1/4] bpf: Factor out bpf_struct_ops_prepare_attach() Amery Hung
2025-07-08 23:08 ` [RFC bpf-next v1 2/4] bpf: Support cookie for linked-based struct_ops attachment Amery Hung
2025-07-09 22:13 ` Martin KaFai Lau
2025-07-10 18:26 ` Martin KaFai Lau
2025-07-10 18:39 ` Amery Hung
2025-07-10 19:47 ` Martin KaFai Lau
2025-07-10 21:00 ` Amery Hung
2025-07-11 18:41 ` Andrii Nakryiko
2025-07-11 19:29 ` Amery Hung
2025-07-11 20:21 ` Alexei Starovoitov
2025-07-11 21:38 ` Amery Hung
2025-07-14 20:46 ` Andrii Nakryiko
2025-07-14 21:02 ` Amery Hung
2025-07-14 22:51 ` Martin KaFai Lau [this message]
2025-07-11 21:55 ` Martin KaFai Lau
2025-07-08 23:08 ` [RFC bpf-next v1 3/4] libbpf: Support link-based struct_ops attach with options Amery Hung
2025-07-08 23:08 ` [RFC bpf-next v1 4/4] selftests/bpf: Test bpf_get_attach_cookie() in struct_ops program Amery Hung
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=2fe9d096-846c-4cb6-ac7e-a9e072cb3281@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=martin.lau@kernel.org \
--cc=tj@kernel.org \
/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).