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 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.