netdev - Re: [RFC 2/2] net: bridge: add a software fast-path implementation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6d85d6a5-190e-2dfd-88f9-f09899c98ee7@nbd.name>
Date:   Mon, 28 Mar 2022 17:15:42 +0200
From:   Felix Fietkau <nbd@....name>
To:     Nikolay Aleksandrov <nikolay@...dia.com>, netdev@...r.kernel.org
Subject: Re: [RFC 2/2] net: bridge: add a software fast-path implementation

Hi Nik,

I'd like to follow up on our discussion regarding bridge offloading.
I managed to come up with a user space + eBPF implementation that 
replaces this code and shows mostly the same performance gain as my 
previous kernel space implementation.

At first I tried to use generic XDP, but after getting it working, 
performance was pretty bad (due to headroom issues) and I was told that 
this is by design and nobody should use it in production.

Then I reworked the code to use tc classifier instead and it worked much 
better.

It's not fully ready yet, I need to add some more tests for incompatible 
features, but I'm getting there...
The code is here: https://github.com/nbd168/bridger

There's one thing I haven't been able to figure out yet: What's the 
proper way to keep bridge fdb entries alive from user space without 
modifying them in any other way?

- Felix