From: Cong Wang <xiyou.wangcong@gmail.com>
To: netdev@vger.kernel.org
Cc: jhs@mojatatu.com, jiri@resnulli.us, toke@redhat.com,
bpf@vger.kernel.org, Cong Wang <cong.wang@bytedance.com>
Subject: [RFC Patch v4 0/2] net_sched: introduce eBPF based Qdisc
Date: Fri, 20 May 2022 10:46:14 -0700 [thread overview]
Message-ID: <20220520174616.74684-1-xiyou.wangcong@gmail.com> (raw)
From: Cong Wang <cong.wang@bytedance.com>
This *incomplete* patch introduces a programmable Qdisc with eBPF.
There are a few use cases:
1. Allow customizing Qdisc's in an easier way. So that people don't
have to write a complete Qdisc kernel module just to experiment
some new queuing theory.
2. Solve EDT's problem. EDT calcuates the "tokens" in clsact which
is before enqueue, it is impossible to adjust those "tokens" after
packets get dropped in enqueue. With eBPF Qdisc, it is easy to
be solved with a shared map between clsact and sch_bpf.
3. Potentially pave a way for ingress to queue packets, although
current implementation is still only for egress.
4. Potentially pave a way for handling TCP protocol in TC, as
rbtree itself is already used by TCP to handle TCP retransmission.
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. This is why I give up on PIFO which has
serious limitations on the programmablity.
Here is a summary of design decisions I made:
1. Avoid eBPF struct_ops, as it would be really hard to program
a Qdisc with this approach, literally all the struct Qdisc_ops
and struct Qdisc_class_ops are needed to implement. This is almost
as hard as programming a Qdisc kernel module.
2. Introduce skb map, which will allow other eBPF programs to store skb's
too.
a) As eBPF maps are not directly visible to the kernel, we have to
dump the stats via eBPF map API's instead of netlink.
b) The user-space is not allowed to read the entire packets, only __sk_buff
itself is readable, because we don't have such a use case yet and it would
require a different API to read the data, as map values have fixed length.
c) Two eBPF helpers are introduced for skb map operations:
bpf_skb_map_push() and bpf_skb_map_pop(). Normal map update is
not allowed.
d) Multi-queue support should be done via map-in-map. This is TBD.
e) Use the netdevice notifier to reset the packets inside skb map upon
NETDEV_DOWN event.
3. Integrate with existing TC infra. For example, if the user doesn't want
to implement her own filters (e.g. a flow dissector), she should be able
to re-use the existing TC filters. Another helper bpf_skb_classify() is
introduced for this purpose.
Any high-level feedback is welcome. Please kindly do not review any coding
details until RFC tag is removed.
TODO:
1. actually test it
2. write a document for this Qdisc
3. add test cases and sample code
Cc: Toke Høiland-Jørgensen <toke@redhat.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <cong.wang@bytedance.com>
---
v4: get rid of PIFO, use rbtree directly
v3: move priority queue from sch_bpf to skb map
introduce skb map and its helpers
introduce bpf_skb_classify()
use netdevice notifier to reset skb's
Rebase on latest bpf-next
v2: Rebase on latest net-next
Make the code more complete (but still incomplete)
Cong Wang (2):
bpf: introduce skb map
net_sched: introduce eBPF based Qdisc
include/linux/bpf_types.h | 2 +
include/linux/skbuff.h | 4 +-
include/uapi/linux/bpf.h | 15 +
include/uapi/linux/pkt_sched.h | 17 ++
kernel/bpf/Makefile | 2 +-
kernel/bpf/skb_map.c | 337 +++++++++++++++++++++
net/sched/Kconfig | 15 +
net/sched/Makefile | 1 +
net/sched/sch_bpf.c | 520 +++++++++++++++++++++++++++++++++
9 files changed, 911 insertions(+), 2 deletions(-)
create mode 100644 kernel/bpf/skb_map.c
create mode 100644 net/sched/sch_bpf.c
--
2.34.1
next reply other threads:[~2022-05-20 17:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-20 17:46 Cong Wang [this message]
2022-05-20 17:46 ` [RFC Patch v4 1/2] bpf: introduce skb map Cong Wang
2022-05-20 17:46 ` [RFC Patch v4 2/2] net_sched: introduce eBPF based Qdisc 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=20220520174616.74684-1-xiyou.wangcong@gmail.com \
--to=xiyou.wangcong@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.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).