| Message ID | 20250305102949.16370-1-ericwouds@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | bridge-fastpath and related improvements | expand |
On 3/5/25 11:29 AM, Eric Woudstra wrote: > This patchset makes it possible to set up a software fastpath between > bridged interfaces. One patch adds the flow rule for the hardware > fastpath. This creates the possibility to have a hardware offloaded > fastpath between bridged interfaces. More patches are added to solve > issues found with the existing code. > Changes in v9: > - No changes, resend to netfilter Hi Pablo, I've changed tag [net-next] to [nf], hopefully you can have a look at this patch-set. But, after some days, I was in doubt if this way I have brought it to your attention. Perhaps I need to do something different to ask the netfilter maintainer have a look at it? Best regards, Eric
Hi, On Tue, Mar 11, 2025 at 09:22:35AM +0100, Eric Woudstra wrote: > > > On 3/5/25 11:29 AM, Eric Woudstra wrote: > > This patchset makes it possible to set up a software fastpath between > > bridged interfaces. One patch adds the flow rule for the hardware > > fastpath. This creates the possibility to have a hardware offloaded > > fastpath between bridged interfaces. More patches are added to solve > > issues found with the existing code. > > > > Changes in v9: > > - No changes, resend to netfilter > > Hi Pablo, > > I've changed tag [net-next] to [nf], hopefully you can have a look at > this patch-set. But, after some days, I was in doubt if this way I have > brought it to your attention. Perhaps I need to do something different > to ask the netfilter maintainer have a look at it? Apologies, this maintainance service is best effort. I am also going to be very busy until April to complete a few more deliverables, I cannot afford more cancelled projects. I will try to collect what is left for net-next and wait for the next merge window. Therefore, I suggest you start with a much smaller series with a carefully selected subset including preparatory patches. I suggest you start with the software enhancements only. Please, add datapath tests. As for the hardware offload part, I have a board that I received 4.5 ago years as a engineering sample that maybe I can use to test this, but no idea, really. You are a passer-by (ahem, "contributor"), this will get merged upstream at some point and we will have to maintain all this new code without your help maybe ... (people change bussiness units...), I have to understand what is going on here. The throughput available is limited, I am afraid we can only go _slow and careful_. Thanks. P.S: You work is important, very important, but maybe there is no need to Cc so many mailing lists and people, maybe netdev@, netfilter-devel@ and bridge@ is sufficient.
On 3/12/25 12:44 AM, Pablo Neira Ayuso wrote: > Therefore, I suggest you start with a much smaller series with a > carefully selected subset including preparatory patches. I suggest you > start with the software enhancements only. Please, add datapath tests. Then I will split it in: 1. Separate preparatory patches and small patch-sets that apply to the forward-fastpath already. 2. One patch-set that brings the bridge-fastpath with datapath tests. > P.S: You work is important, very important, but maybe there is no need > to Cc so many mailing lists and people, maybe netdev@, > netfilter-devel@ and bridge@ is sufficient. Ok, but my main question then is which tree should I work in, and therefore which tag should I give my patches, [nf] or [net-next]. I think it will get more complicated if I split my patch-set and half of the patches go to [nf] and another half to [net-next]. What do you suggest?
On Wed, Mar 12, 2025 at 05:21:29PM +0100, Eric Woudstra wrote: > > > On 3/12/25 12:44 AM, Pablo Neira Ayuso wrote: > > Therefore, I suggest you start with a much smaller series with a > > carefully selected subset including preparatory patches. I suggest you > > start with the software enhancements only. Please, add datapath tests. > > Then I will split it in: > 1. Separate preparatory patches and small patch-sets that apply > to the forward-fastpath already. > 2. One patch-set that brings the bridge-fastpath with datapath tests. > > > P.S: You work is important, very important, but maybe there is no need > > to Cc so many mailing lists and people, maybe netdev@, > > netfilter-devel@ and bridge@ is sufficient. > > Ok, but my main question then is which tree should I work in, and > therefore which tag should I give my patches, [nf] or [net-next]. > I think it will get more complicated if I split my patch-set and half of > the patches go to [nf] and another half to [net-next]. Use [nf-next]. > What do you suggest? Probably I can collect 4/15 and 5/15 from this series to be included in the next pull request, let me take a look. But it would be good to have tests for these two patches. I would suggest you continue by making a series to add bridge support for the flowtable, software only, including tests. Once this gets merged, then follow up with the hardware offload code. Thanks.
This patchset makes it possible to set up a software fastpath between bridged interfaces. One patch adds the flow rule for the hardware fastpath. This creates the possibility to have a hardware offloaded fastpath between bridged interfaces. More patches are added to solve issues found with the existing code. To set up the fastpath with offloading, add this extra flowtable: table bridge filter { flowtable fb { hook ingress priority filter devices = { lan0, lan1, lan2, lan3, lan4, wlan0, wlan1 } flags offload } chain forward { type filter hook forward priority filter; policy accept; ct state established flow add @fb } } Creating a separate fastpath for bridges. forward fastpath bypass .----------------------------------------. / \ | IP - forwarding | | / \ v | / wan ... | / | | | | | brlan.1 | | | +-------------------------------+ | | vlan 1 | | | | | | brlan (vlan-filtering) | | +---------------+ | | | DSA-SWITCH | | | | | vlan 1 | | | | to | | | vlan 1 | untagged | | +---------------+---------------+ . / \ ------>lan0 wlan1 . ^ ^ . | | . \_________________/ . bridge fastpath bypass . ^ vlan 1 tagged packets To have the ability to handle xmit direct with outgoing encaps in the bridge fastpass bypass, we need to be able to handle them without going through vlan/pppoe devices. So I've applied, amended and squashed wenxu's patchset. This patch also makes it possible to egress from vlan-filtering brlan to lan0 with vlan tagged packets, if the bridge master port is doing the vlan tagging, instead of the vlan-device. Without this patch, this is not possible in the bridge-fastpath and also not in the forward-fastpath, as seen in the figure above. There are also some more fixes for filling in the forward path. These fixes also apply to for the forward-fastpath. They include handling DEV_PATH_MTK_WDMA in nft_dev_path_info(). There are now 2 patches for avoiding ingress_vlans bit set for bridged dsa user ports and foreign (dsa) ports. Another patch introduces DEV_PATH_BR_VLAN_KEEP_HW, needed for the bridge-fastpath only. Conntrack bridge only tracks untagged and 802.1q. To make the bridge fastpath experience more similar to the forward fastpath experience, I've added double vlan, pppoe and pppoe-in-q tagged packets to bridge conntrack and to bridge filter chain. Note: While testing direct transmit in the software forward-fastpath, without the capability of setting the offload flag, it is sometimes useful to enslave the wan interface to another bridge, brwan. This will make sure both directions of the software forward-fastpath use direct transmit, which also happens when the offload flag is set. I have send RFC v2 as I previously only owned a dsa device. I now have obtained a switchdev supporting SWITCHDEV_OBJ_ID_PORT_VLAN, and found there was more to do to handle the ingress_vlans bit and corresponding vlan encap. I send v4 and above as non-RFC as the previous 2 RFC's did not get any comment. Changes in v9: - No changes, resend to netfilter Changes in v8: - Added commit on top: Avoid zero-length arrays in struct pppoe_hdr. Changes in v7: - Inside br_vlan_fill_forward_path_pvid(), replaced usage of br_vlan_group() with br_vlan_group_rcu() and nbp_vlan_group() with nbp_vlan_group_rcu(). Changes in v6: - Conntrack double vlan and pppoe patch: Set ph and vhdr after the calls to pskb_may_pull(). Changes in v5: - Conntrack double vlan and pppoe patch: Moved pskb_may_pull() up to the first switch statement, to the start of the cases. Removed the second switch statement. Replaced 0xffffffff with U32_MAX. - Added patch removing hw_outdev, out.hw_ifindex and out.hw_ifidx members. - Fix error path returned from nft_flow_offload_bridge_init(). - Cosmetics. Changes in v4: - Added !CONFIG_NET_SWITCHDEV version of br_switchdev_port_vlan_no_foreign_add(). Changes in v3: - Squashed the two 'port to port' patches to avoid build errors when only one of the two commits is applied. Changes in v2: - Introduce DEV_PATH_BR_VLAN_KEEP_HW for use in the bridge-fastpath only. It is needed for switchdevs supporting SWITCHDEV_OBJ_ID_PORT_VLAN. - Different approach for handling BR_VLFLAG_ADDED_BY_SWITCHDEV in br_vlan_fill_forward_path_mode() for foreign devices. Introduce SWITCHDEV_F_NO_FOREIGN, BR_VLFLAG_TAGGING_BY_SWITCHDEV and br_switchdev_port_vlan_no_foreign_add(). The latter function can be used to make sure the vlan was added to a switchdev native device. When that fails, adding the vlan with br_switchdev_port_vlan_add() means it was added to a switchdev foreign device. - Clear ingress_vlans bit and corresponding encap for dsa user ports. - Add check for ingress_vlans bit to nft_dev_fill_bridge_path(). - Adapted cover letter description to make clear the patches apply to software fastpath, making hardware-offloaded fastpath possible. - Fixed clang error for vlan_hdr * and struct ppp_hdr * by adding block. - Updated !CONFIG_BRIDGE_VLAN_FILTERING version of br_vlan_fill_forward_path_pvid(). - Removed erroneous check netif_is_bridge_master(ctx->dev) from dev_fill_bridge_path(). - Cosmetic changes. Eric Woudstra (15): net: pppoe: avoid zero-length arrays in struct pppoe_hdr netfilter: nf_flow_table_offload: Add nf_flow_encap_push() for xmit direct netfilter: flow: remove hw_outdev, out.hw_ifindex and out.hw_ifidx netfilter: bridge: Add conntrack double vlan and pppoe netfilter: nft_chain_filter: Add bridge double vlan and pppoe bridge: Add filling forward path from port to port net: core: dev: Add dev_fill_bridge_path() netfilter :nf_flow_table_offload: Add nf_flow_rule_bridge() netfilter: nf_flow_table_inet: Add nf_flowtable_type flowtable_bridge netfilter: nft_flow_offload: Add NFPROTO_BRIDGE to validate netfilter: nft_flow_offload: Add DEV_PATH_MTK_WDMA to nft_dev_path_info() netfilter: nft_flow_offload: No ingress_vlan forward info for dsa user port bridge: No DEV_PATH_BR_VLAN_UNTAG_HW for dsa foreign bridge: Introduce DEV_PATH_BR_VLAN_KEEP_HW for bridge-fastpath netfilter: nft_flow_offload: Add bridgeflow to nft_flow_offload_eval() drivers/net/ppp/pppoe.c | 2 +- include/linux/netdevice.h | 3 + include/net/netfilter/nf_flow_table.h | 5 +- include/net/switchdev.h | 1 + include/uapi/linux/if_pppox.h | 4 + net/bridge/br_device.c | 23 ++- net/bridge/br_private.h | 12 ++ net/bridge/br_switchdev.c | 15 ++ net/bridge/br_vlan.c | 29 +++- net/bridge/netfilter/nf_conntrack_bridge.c | 83 ++++++++-- net/core/dev.c | 66 ++++++-- net/netfilter/nf_flow_table_core.c | 1 - net/netfilter/nf_flow_table_inet.c | 13 ++ net/netfilter/nf_flow_table_ip.c | 96 +++++++++++- net/netfilter/nf_flow_table_offload.c | 15 +- net/netfilter/nft_chain_filter.c | 20 ++- net/netfilter/nft_flow_offload.c | 168 +++++++++++++++++++-- net/switchdev/switchdev.c | 2 +- 18 files changed, 497 insertions(+), 61 deletions(-)