| Message ID | 1596170660-5582-1-git-send-email-komachi.yoshiki@gmail.com |
|---|---|
| Headers | show |
| Series | Add a new bpf helper for FDB lookup | expand |
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
Thanks for giving me a lot of comments! Find my response below, please. > 2020/08/01 6:52、John Fastabend <john.fastabend@gmail.com>のメール: > > 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. As you described above, learning and aging don’t work at this point. IMO, another helper for learning will be required to fill the requirements. I guess that the helper will enable us to use the aging feature as well because the aging is the functionality of bridge fdb. > 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. As for the vlan filtering, I think it doesn't necessarily have to be like that. I have the following ideas to achieve it for now: 1. Monitoring vlan events in bridges by a userspace daemon and it notifies XDP programs of the events through BPF maps 2. Another bpf helper to retrieve bridge vlan information The additional helper will be required only if the 2nd one is accepted. I would like to discuss which is better because there are pros and cons. On the other hand, the helper for the learning feature should be added, IMO. But, I guess that the learning feature is just sufficient to get the aging feature because bridges with learning have capability for aging as well. > 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. Sorry, I have not measured the performance numbers yet, so I will try it later. > 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. For example, it is useful in libvirt with macTableManager. This feature makes it possible for static bridges to process packets faster than other ones with learning. However, it doesn't work properly if the vlan filtering is not enabled. > I guess to get STP working you would minimally need learning and > aging? I guess that STP seems not to be related to learning and aging, but there may be the following requirements if it is added in the future: 1. BPDU frames are transferred to normal bridges by the XDP_PASS action 2. closing targeted ports based on the STP configurations To meet the 2nd one, another bpf helper may be required. There is a possibility that bpf maps help to achieve this as another approach. Thanks & Best regards, > Thanks, > John — Yoshiki Komachi komachi.yoshiki@gmail.com
On 8/5/20 4:26 AM, Yoshiki Komachi wrote: >> >> 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. > > As you described above, learning and aging don’t work at this point. > > IMO, another helper for learning will be required to fill the requirements. > I guess that the helper will enable us to use the aging feature as well > because the aging is the functionality of bridge fdb. One option is to have a flag that bumps the ageing on successful lookup and do that in 1 call. You will already have access to the fdb entry.
> 2020/08/06 1:36、David Ahern <dsahern@gmail.com>のメール: > > On 8/5/20 4:26 AM, Yoshiki Komachi wrote: >>> >>> 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. >> >> As you described above, learning and aging don’t work at this point. >> >> IMO, another helper for learning will be required to fill the requirements. >> I guess that the helper will enable us to use the aging feature as well >> because the aging is the functionality of bridge fdb. > > One option is to have a flag that bumps the ageing on successful lookup > and do that in 1 call. You will already have access to the fdb entry. It seems like a good idea to me! I guess that the flags in my suggested bpf helper for the FDB lookup will be useful for such a case. Thanks & Best regards, — Yoshiki Komachi komachi.yoshiki@gmail.com
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. Patch 1 adds new function for access FDB in the kernel tables via the new bpf helper. Patch 2 adds the bpf helper and 3 adds a sample program. Yoshiki Komachi (3): net/bridge: Add new function to access FDB from XDP programs bpf: Add helper to do forwarding lookups in kernel FDB table samples/bpf: Add a simple bridge example accelerated with XDP include/linux/if_bridge.h | 11 ++ include/uapi/linux/bpf.h | 28 ++++ net/bridge/br_fdb.c | 25 ++++ net/core/filter.c | 45 +++++++ samples/bpf/Makefile | 3 + samples/bpf/xdp_bridge_kern.c | 129 ++++++++++++++++++ samples/bpf/xdp_bridge_user.c | 239 +++++++++++++++++++++++++++++++++ scripts/bpf_helpers_doc.py | 1 + tools/include/uapi/linux/bpf.h | 28 ++++ 9 files changed, 509 insertions(+) create mode 100644 samples/bpf/xdp_bridge_kern.c create mode 100644 samples/bpf/xdp_bridge_user.c