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
| ||
|
Date: Fri, 31 Jul 2020 14:52:46 -0700 From: John Fastabend <john.fastabend@...il.com> To: Yoshiki Komachi <komachi.yoshiki@...il.com>, "David S. Miller" <davem@...emloft.net>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>, Jakub Kicinski <kuba@...nel.org>, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>, KP Singh <kpsingh@...omium.org>, Roopa Prabhu <roopa@...ulusnetworks.com>, Nikolay Aleksandrov <nikolay@...ulusnetworks.com>, David Ahern <dsahern@...nel.org> Cc: Yoshiki Komachi <komachi.yoshiki@...il.com>, netdev@...r.kernel.org, bridge@...ts.linux-foundation.org, bpf@...r.kernel.org Subject: RE: [RFC PATCH bpf-next 0/3] Add a new bpf helper for FDB lookup Yoshiki Komachi wrote: > This series adds a new bpf helper for doing FDB lookup in the kernel > tables from XDP programs. This helps users to accelerate Linux bridge > with XDP. > > In the past, XDP generally required users to reimplement their own > networking functionalities with specific manners of BPF programming > by themselves, hindering its potential uses. IMO, bpf helpers to > access networking stacks in kernel help to mitigate the programming > costs because users reuse mature Linux networking feature more easily. > > The previous commit 87f5fc7e48dd ("bpf: Provide helper to do forwarding > lookups in kernel FIB table") have already added a bpf helper for access > FIB in the kernel tables from XDP programs. As a next step, this series > introduces the API for FDB lookup. In the future, other bpf helpers for > learning and VLAN filtering will also be required in order to realize > fast XDP-based bridge although these are not included in this series. Just to clarify for myself. I expect that with just the helpers here we should only expect static configurations to work, e.g. any learning and/or aging is not likely to work if we do redirects in the XDP path. Then next to get a learning/filtering/aging we would need to have a set of bridge helpers to get that functionality as well? I believe I'm just repeating what you are saying above, but wanted to check. Then my next question is can we see some performance numbers? These things are always trade-off between performance and ease of use, but would be good to know roughly what we are looking at vs a native XDP bridge functionality. Do you have a use case for a static bridge setup? Nothing wrong to stage things IMO if the 'real' use case needs learning and filtering. I guess to get STP working you would minimally need learning and aging? Thanks, John
Powered by blists - more mailing lists