From: Martin KaFai Lau <martin.lau@linux.dev>
To: Amery Hung <ameryhung@gmail.com>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
alexei.starovoitov@gmail.com, andrii@kernel.org,
daniel@iogearbox.net, edumazet@google.com, kuba@kernel.org,
xiyou.wangcong@gmail.com, jhs@mojatatu.com,
martin.lau@kernel.org, jiri@resnulli.us, stfomichev@gmail.com,
toke@redhat.com, sinquersw@gmail.com,
ekarani.silvestre@ccc.ufcg.edu.br, yangpeihao@sjtu.edu.cn,
yepeilin.cs@gmail.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v7 03/10] bpf: net_sched: Add basic bpf qdisc kfuncs
Date: Fri, 11 Apr 2025 13:11:25 -0700 [thread overview]
Message-ID: <10ca0a54-18b0-43fd-bf70-c1ab15349e87@linux.dev> (raw)
In-Reply-To: <CAMB2axNeb-UzO8AOkdXPcqrwnw2J6vKVLSRVM_R+oN=SJEsx9g@mail.gmail.com>
On 4/11/25 1:03 PM, Amery Hung wrote:
>> The same goes for the bpf_kfree_skb(). I was thinking if it is useful at all
>> considering there is already a bpf_qdisc_skb_drop(). I kept it there because it
>> is a little more intuitive in case the .reset/.destroy wanted to do a "skb =
>> bpf_kptr_xchg(&skbn->skb, NULL);" and then explicitly free the
>> bpf_kfree_skb(skb). However, the bpf prog can also directly do the
>> bpf_obj_drop(skbn) and then bpf_kfree_skb() is not needed, right?
>>
>>
>
> My rationale for keeping two skb releasing kfuncs: bpf_kfree_skb() is
> the dtor and since dtor can only have one argument, so
> bpf_qdisc_skb_drop() can not replace it. Since bpf_kfree_skb() is here
> to stay, I allow users to call it directly for convenience. Only
> exposing bpf_qdisc_skb_drop() and calling kfree_skb() in
> bpf_qdisc_skb_drop() when to_free is NULL will also do. I don’t have a
> strong opinion.
>
> Yes, bpf_kfree_skb() will not be needed if doing bpf_obj_drop(skbn).
> bpf_obj_drop() internally will call the dtor of a kptr (i.e., in this
> case, bpf_kfree_skb()) in an allocated object.
Make sense. Lets keep the bpf_kfree_skb() as-is instead of complicating the
bpf_qdisc_skb_drop() with NULL vs non-NULL argument.
next prev parent reply other threads:[~2025-04-11 20:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 21:45 [PATCH bpf-next v7 00/10] bpf qdisc Amery Hung
2025-04-09 21:45 ` [PATCH bpf-next v7 01/10] bpf: Prepare to reuse get_ctx_arg_idx Amery Hung
2025-04-09 21:45 ` [PATCH bpf-next v7 02/10] bpf: net_sched: Support implementation of Qdisc_ops in bpf Amery Hung
2025-04-10 23:49 ` Martin KaFai Lau
2025-04-09 21:45 ` [PATCH bpf-next v7 03/10] bpf: net_sched: Add basic bpf qdisc kfuncs Amery Hung
2025-04-11 13:32 ` Kumar Kartikeya Dwivedi
2025-04-11 16:58 ` Amery Hung
2025-04-11 17:08 ` Kumar Kartikeya Dwivedi
2025-04-11 17:17 ` Amery Hung
2025-04-11 17:22 ` Kumar Kartikeya Dwivedi
2025-04-11 18:36 ` Martin KaFai Lau
2025-04-11 20:03 ` Amery Hung
2025-04-11 20:11 ` Martin KaFai Lau [this message]
2025-04-09 21:46 ` [PATCH bpf-next v7 04/10] bpf: net_sched: Add a qdisc watchdog timer Amery Hung
2025-04-09 21:46 ` [PATCH bpf-next v7 05/10] bpf: net_sched: Support updating bstats Amery Hung
2025-04-09 21:46 ` [PATCH bpf-next v7 06/10] bpf: net_sched: Disable attaching bpf qdisc to non root Amery Hung
2025-04-09 21:46 ` [PATCH bpf-next v7 07/10] libbpf: Support creating and destroying qdisc Amery Hung
2025-04-09 21:46 ` [PATCH bpf-next v7 08/10] selftests/bpf: Add a basic fifo qdisc test Amery Hung
2025-04-10 23:59 ` Martin KaFai Lau
2025-04-11 17:20 ` Amery Hung
2025-04-09 21:46 ` [PATCH bpf-next v7 09/10] selftests/bpf: Add a bpf fq qdisc to selftest Amery Hung
2025-04-09 21:46 ` [PATCH bpf-next v7 10/10] selftests/bpf: Test attaching bpf qdisc to mq and non root Amery Hung
2025-04-10 23:50 ` [PATCH bpf-next v7 00/10] bpf qdisc patchwork-bot+netdevbpf
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=10ca0a54-18b0-43fd-bf70-c1ab15349e87@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=edumazet@google.com \
--cc=ekarani.silvestre@ccc.ufcg.edu.br \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=martin.lau@kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sinquersw@gmail.com \
--cc=stfomichev@gmail.com \
--cc=toke@redhat.com \
--cc=xiyou.wangcong@gmail.com \
--cc=yangpeihao@sjtu.edu.cn \
--cc=yepeilin.cs@gmail.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 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.