[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpUjJ+goqoFX+vPUXbcvt3oDga2UgA-MKMXJh9iYY8j_6g@mail.gmail.com>
Date: Fri, 3 Sep 2021 18:09:46 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Martin KaFai Lau <kafai@...com>
Cc: Toke Høiland-Jørgensen <toke@...hat.com>,
John Fastabend <john.fastabend@...il.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, Cong Wang <cong.wang@...edance.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>
Subject: Re: [RFC Patch net-next] net_sched: introduce eBPF based Qdisc
On Wed, Sep 1, 2021 at 10:45 AM Martin KaFai Lau <kafai@...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.
And kfunc call really sucks, it does not even guarantee a stable ABI, it
is a serious mistake you made for eBPF.
Thanks.
Powered by blists - more mailing lists