netdev - Re: [RFC PATCH v7 7/8] samples/bpf: Add an example of bpf fq qdisc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMB2axPPxq5yF21e-V-JJBoZO4C+EKABCcM2GnEsVZLSecNurw@mail.gmail.com>
Date: Fri, 26 Jan 2024 11:49:17 -0800
From: Amery Hung <ameryhung@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org, yangpeihao@...u.edu.cn, 
	toke@...hat.com, jhs@...atatu.com, jiri@...nulli.us, sdf@...gle.com, 
	xiyou.wangcong@...il.com, yepeilin.cs@...il.com
Subject: Re: [RFC PATCH v7 7/8] samples/bpf: Add an example of bpf fq qdisc

On Wed, Jan 24, 2024 at 2:29 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> On 1/17/24 10:56 PM, Amery Hung wrote:
> > tc_sch_fq.bpf.c
> > A simple bpf fair queueing (fq) qdisc that gives each flow a euqal chance
> > to transmit data. The qdisc respects the timestamp in a skb set by an
> > clsact rate limiter. It can also inform the rate limiter about packet drop
> > when enabled to adjust timestamps. The implementation does not prevent hash
> > collision of flows nor does it recycle flows.
> >
> > tc_sch_fq.c
> > A user space program to load and attach the eBPF-based fq qdisc, which
> > by default add the bpf fq to the loopback device, but can also add to other
> > dev and class with '-d' and '-p' options.
> >
> > To test the bpf fq qdisc with the EDT rate limiter:
> > $ tc qdisc add dev lo clsact
> > $ tc filter add dev lo egress bpf obj tc_clsact_edt.bpf.o sec classifier
> > $ ./tc_sch_fq -s
>
> Would be nice if you also include a performance comparison (did you do
> production tests with it?) with side-by-side to native fq and if you see
> a delta elaborate on what would be needed to address it.

I did a simple test by adding a fq to the loopback device and then
sending a single stream traffic via iperf. The bpf implementation of
fq achieves 90% throughput compared with the native one.

I think the overhead mainly comes from allocating bpf objects (struct
skb_node) to store skb kptrs. This part can be removed if bpf
list/rbtree recognizes skb->list/rbnode. On the kfunc implementation
side, I think we can do it by saving struct bpf_rb_node_kern into
skb->rb_node and skb->cb. I haven't looked into the verifier to see
what needs to be done.

I will move the test cases from samples to selftests and include more
testing in the next patchset.

>
> > Signed-off-by: Amery Hung <amery.hung@...edance.com>
> > ---
> >   samples/bpf/Makefile            |   8 +-
> >   samples/bpf/bpf_experimental.h  | 134 +++++++
> >   samples/bpf/tc_clsact_edt.bpf.c | 103 +++++
> >   samples/bpf/tc_sch_fq.bpf.c     | 666 ++++++++++++++++++++++++++++++++
> >   samples/bpf/tc_sch_fq.c         | 321 +++++++++++++++
> >   5 files changed, 1231 insertions(+), 1 deletion(-)
> >   create mode 100644 samples/bpf/bpf_experimental.h
> >   create mode 100644 samples/bpf/tc_clsact_edt.bpf.c
> >   create mode 100644 samples/bpf/tc_sch_fq.bpf.c
> >   create mode 100644 samples/bpf/tc_sch_fq.c