From: Martin KaFai Lau <kafai@fb.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"Linux Kernel Network Developers" <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, "Cong Wang" <cong.wang@bytedance.com>,
"Jamal Hadi Salim" <jhs@mojatatu.com>,
"Jiri Pirko" <jiri@resnulli.us>
Subject: Re: [RFC Patch net-next] net_sched: introduce eBPF based Qdisc
Date: Thu, 16 Sep 2021 21:19:03 -0700 [thread overview]
Message-ID: <20210917041903.yuepvbvajtheuvct@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <CAM_iQpUjJ+goqoFX+vPUXbcvt3oDga2UgA-MKMXJh9iYY8j_6g@mail.gmail.com>
On Fri, Sep 03, 2021 at 06:09:46PM -0700, Cong Wang wrote:
> On Wed, Sep 1, 2021 at 10:45 AM Martin KaFai Lau <kafai@fb.com> wrote:
> > _if_ it is using as a qdisc object/interface,
> > the patch "looks" easier because it obscures some of the ops/interface
> > from the bpf user. The user will eventually ask for more flexibility
> > and then an on-par interface as the kernel's qdisc. If there are some
> > common 'ops', the common bpf code can be shared as a library in userspace
> > or there is also kfunc call to call into the kernel implementation.
> > For existing kernel qdisc author, it will be easier to use the same
> > interface also.
>
> Thanks for showing the advantages of a kernel module. And no, we
> are not writing kernel modules in eBPF.
The line is very blurry between a bpf_prog and kernel module,
especially with the advancement of bpf, btf, and CO-RE.
Both bpf_prog.o (struct_ops or not) and some_native_kern_mod.ko are attaching
to some kernel hooks to be called. If writing bpf and attaching it to a hook
does not work for you, bpf does not fit your case.
> And kfunc call really sucks, it does not even guarantee a stable ABI, it
> is a serious mistake you made for eBPF.
Not ture. It depends on what is allowed to be called by bpf.
Needless to say I cannot agree with the "sucks" description.
This kind of dismissive discussion is worse than unproductive
and not the best way to use the mailing list time.
next prev parent reply other threads:[~2021-09-17 4:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-21 1:02 [RFC Patch net-next] net_sched: introduce eBPF based Qdisc Cong Wang
2021-08-24 23:47 ` Martin KaFai Lau
2021-09-01 4:39 ` Cong Wang
2021-09-01 5:45 ` John Fastabend
2021-09-01 10:42 ` Toke Høiland-Jørgensen
2021-09-01 17:45 ` Martin KaFai Lau
2021-09-01 18:03 ` Alexei Starovoitov
2021-09-02 16:57 ` Toke Høiland-Jørgensen
2021-09-02 20:40 ` John Fastabend
2021-09-02 22:27 ` Toke Høiland-Jørgensen
2021-09-02 23:35 ` Martin KaFai Lau
2021-09-03 14:44 ` Toke Høiland-Jørgensen
2021-09-03 15:33 ` Jamal Hadi Salim
2021-09-10 6:55 ` Martin KaFai Lau
2021-09-10 11:31 ` Toke Høiland-Jørgensen
2021-09-04 1:09 ` Cong Wang
2021-09-17 4:19 ` Martin KaFai Lau [this message]
2021-09-04 1:30 ` Cong Wang
2021-09-06 11:45 ` Toke Høiland-Jørgensen
2021-09-04 1:05 ` Cong Wang
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=20210917041903.yuepvbvajtheuvct@kafai-mbp.dhcp.thefacebook.com \
--to=kafai@fb.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.com \
--cc=xiyou.wangcong@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 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).