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 [off-list ref] wrote:

quoted

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