From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Cong Wang <xiyou.wangcong@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Cong Wang <cong.wang@bytedance.com>,
Jiri Pirko <jiri@resnulli.us>
Subject: Re: [RFC Patch net-next v2] net_sched: introduce eBPF based Qdisc
Date: Fri, 1 Oct 2021 09:43:13 -0400 [thread overview]
Message-ID: <6d648f13-756f-0e3e-b617-5f9244d733b7@mojatatu.com> (raw)
In-Reply-To: <CAADnVQJX8OpXhQ66jVSN1ws8tav5R8yCERr6eaS9POA+QhRx-A@mail.gmail.com>
On 2021-09-29 4:57 p.m., Alexei Starovoitov wrote:
> Applying queuing discipline to non-skb context may be not your target
> but it's a reasonable and practical request to have.
While i agree that it is useful to deal with queues and scheduling
for other buffer contexts, it certainly not the same infrastructure
wise to deal with sending a context to user space vs dealing with
the qdisc environment. There are a lot of corner cases of dealing with
the mix of hard and softirqs, non-work conserving modes, multiflow
funneling and locking etc that have been refined over the years that
are incorporated into the tc + netdev infra.
The approach that Cong took of just reusing that infra will take
advantage of those learnings. The only thing that is variable between
the different qdiscs is the enqueue/dequeue algos (which is where
Cong is sticking the ebpf hooks). To me that looks like a very
good starting point as i dont believe you can come up with one size
fits all without excessive over-engineering (which seems to defeat
the purpose of ebpf).
cheers,
jamal
prev parent reply other threads:[~2021-10-01 13:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 23:11 [RFC Patch net-next v2] net_sched: introduce eBPF based Qdisc Cong Wang
2021-09-17 18:18 ` Alexei Starovoitov
2021-09-22 3:59 ` Cong Wang
2021-09-22 4:03 ` Alexei Starovoitov
2021-09-22 4:13 ` Cong Wang
2021-09-23 1:49 ` Alexei Starovoitov
2021-09-23 2:05 ` Alexei Starovoitov
2021-09-29 11:47 ` Toke Høiland-Jørgensen
2021-09-29 5:40 ` Cong Wang
2021-09-29 20:57 ` Alexei Starovoitov
2021-10-01 13:43 ` Jamal Hadi Salim [this message]
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=6d648f13-756f-0e3e-b617-5f9244d733b7@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--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).