Thread (11 messages) 11 messages, 4 authors, 2021-10-01

Re: [RFC Patch net-next v2] net_sched: introduce eBPF based Qdisc

From: Cong Wang <hidden>
Date: 2021-09-22 04:13:25
Also in: bpf

On Tue, Sep 21, 2021 at 9:03 PM Alexei Starovoitov
[off-list ref] wrote:
On Tue, Sep 21, 2021 at 8:59 PM Cong Wang [off-list ref] wrote:
quoted
On Fri, Sep 17, 2021 at 11:18 AM Alexei Starovoitov
[off-list ref] wrote:
quoted
On Mon, Sep 13, 2021 at 6:27 PM Cong Wang [off-list ref] wrote:
quoted
---
v2: Rebase on latest net-next
    Make the code more complete (but still incomplete)
What is the point of v2 when feedback on the first RFC was ignored?
They are not ignored for two reasons:

1) I responded to those reasonable ones in the original thread. Clearly
you missed them.
Multiple people in the v1 thread made it clear that the approach
presented in v1 is not generic enough. v2 made no attempt to
address these concerns.
It looks like you just missed the first part:

"This *incomplete* patch introduces a programmable Qdisc with
eBPF.  The goal is to make this Qdisc as programmable as possible,
that is, to replace as many existing Qdisc's as we can, no matter
in tree or out of tree. And we want to make programmer's and researcher's
life as easy as possible, so that they don't have to write a complete
Qdisc kernel module just to experiment some queuing theory."

If you compare it with V1, V2 explains the use case in more details,
which is to target Qdisc writers, not any other. Therefore, the argument
of making it out of Qdisc is non-sense, anything outside of Qdisc is
not even my target. Of course you can do anything in XDP, but it has
absolutely nothing with my goal here: Qdisc.

I also addressed the skb map concern:

" 2b) Kernel would lose the visibility of the "queues", as maps are only
   shared between eBPF programs and user-space. These queues still have to
   interact with the kernel, for example, kernel wants to reset all queues
   when we reset the network interface, kernel wants to adjust number of
   queues if they are mapped to hardware queues."

More than writing, I even tried to write a skb map by myself, I don't
see it fits into my goal at all. Therefore, the only thing I can do is just to
expand my changelog to explain why.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help