From: Nikolay Aleksandrov <razor@blackwall.org> To: netdev@vger.kernel.org Cc: roopa@nvidia.com, bridge@lists.linux-foundation.org, Nikolay Aleksandrov <nikolay@nvidia.com> Subject: [PATCH net-next 00/15] net: bridge: multicast: add vlan support Date: Mon, 19 Jul 2021 20:06:22 +0300 [thread overview] Message-ID: <20210719170637.435541-1-razor@blackwall.org> (raw) From: Nikolay Aleksandrov <nikolay@nvidia.com> Hi all, This patchset adds initial per-vlan multicast support, most of the code deals with moving to multicast context pointers from bridge/port pointers. That allows us to switch them with the per-vlan contexts when a multicast packet is being processed and vlan multicast snooping has been enabled. That is controlled by a global bridge option added in patch 06 which is off by default (BR_BOOLOPT_MCAST_VLAN_SNOOPING). It is important to note that this option can change only under RTNL and doesn't require multicast_lock, so we need to be careful when retrieving mcast contexts in parallel. For packet processing they are switched only once in br_multicast_rcv() and then used until the packet has been processed. For the most part we need these contexts only to read config values and check if they are disabled. The global mcast state which is maintained consists of querier and router timers, the rest are config options. The port mcast state which is maintained consists of query timer and link to router port list if it's ever marked as a router port. Port multicast contexts _must_ be used only with their respective global contexts, that is a bridge port's mcast context must be used only with bridge's global mcast context and a vlan/port's mcast context must be used only with that vlan's global mcast context due to the router port lists. This way a bridge port can be marked as a router in multiple vlans, but might not be a router in some other vlan. Also this allows us to have per-vlan querier elections, per-vlan queries and basically the whole multicast state becomes per-vlan when the option is enabled. One of the hardest parts is synchronization with vlan's memory management, that is done through a new vlan flag: BR_VLFLAG_MCAST_ENABLED which is changed only under multicast_lock. When a vlan is being destroyed first that flag is removed under the lock, then the multicast context is torn down which includes waiting for any outstanding context timers. Since all of the vlan processing depends on BR_VLFLAG_MCAST_ENABLED it must be checked first if the contexts are vlan and the multicast_lock has been acquired. That is done by all IGMP/MLD packet processing functions and timers. When processing a packet we have RCU so the vlan memory won't be freed, but if the flag is missing we must not process it. The timers are synchronized in the same way with the addition of waiting for them to finish in case they are running after removing the flag under multicast_lock (i.e. they were waiting for the lock). Multicast vlan snooping requires vlan filtering to be enabled, if it's disabled then snooping gets automatically disabled, too. BR_VLFLAG_GLOBAL_MCAST_ENABLED controls if a vlan has BR_VLFLAG_MCAST_ENABLED set which is used in all vlan disabled checks. We need both flags because one is controlled by user-space globally (BR_VLFLAG_GLOBAL_MCAST_ENABLED) and the other is for a particular bridge/vlan or port/vlan entry (BR_VLFLAG_MCAST_ENABLED). Since the latter is also used for synchronization between the multicast and vlan code, and also controlled by BR_VLFLAG_GLOBAL_MCAST_ENABLED we rely on it when checking if a vlan context is disabled. The multicast fast-path has 3 new bit tests on the cache-hot bridge flags field, I didn't observe any measurable difference. I haven't forced either context options to be always disabled when the other type is enabled because the state consists of timers which either expire (router) or don't affect the normal operation. Some options, like the mcast querier one, won't be allowed to change for the disabled context type, that will come with a future patch-set which adds per-vlan querier control. Another important addition is the global vlan options, so far we had only per bridge/port vlan options but in order to control vlan multicast snooping globally we need to add a new type of global vlan options. They can be changed only on the bridge device and are dumped only when a special flag is set in the dump request. The first global option is vlan mcast snooping control, it controls the vlan BR_VLFLAG_GLOBAL_MCAST_ENABLED private flag. It can be set only on master vlan entries. There will be many more global vlan options in the future both for multicast config and other per-vlan options (e.g. STP). There's a lot of room for improvements, I'll do some of the initial ones but splitting the state to different contexts opens the door for a lot more. Also any new multicast options become vlan-supported with very little to no effort by using the same contexts. Short patch description: patches 01-04: initial mcast context add, no functional changes patch 05: adds vlan mcast init and control helpers and uses them on vlan create/destroy patch 06: adds a global bridge mcast vlan snooping knob (default off) patches 07-08: add a helper for users which must derive the contexts based on current bridge and vlan options (e.g. timers) patch 09: adds checks for disabled vlan contexts in packet processing and timers patch 10: adds support for per-vlan querier and tagged queries patch 11: adds router port vlan id in the notifications patches 12-14: add global vlan options support (change, dump, notify) patch 15: adds per-vlan global mcast snooping control Future patch-sets which build on this one (in order): - vlan state mcast handling - user-space mdb contexts (currently only the bridge contexts are used there) - all bridge multicast config options added per-vlan global and per vlan/port - iproute2 support for all the new uAPIs - selftests This set has been stress-tested (deleting/adding ports/vlans while changing vlan mcast snooping while processing IGMP/MLD packets), and also has passed all bridge self-tests. I'm sending this set as early as possible since there're a few more related sets that should go in the same release to get proper and full mcast vlan snooping support. Thanks, Nik Nikolay Aleksandrov (15): net: bridge: multicast: factor out port multicast context net: bridge: multicast: factor out bridge multicast context net: bridge: multicast: use multicast contexts instead of bridge or port net: bridge: vlan: add global and per-port multicast context net: bridge: multicast: add vlan state initialization and control net: bridge: add vlan mcast snooping knob net: bridge: multicast: add helper to get port mcast context from port group net: bridge: multicast: use the port group to port context helper net: bridge: multicast: check if should use vlan mcast ctx net: bridge: multicast: add vlan querier and query support net: bridge: multicast: include router port vlan id in notifications net: bridge: vlan: add support for global options net: bridge: vlan: add support for dumping global vlan options net: bridge: vlan: notify when global options change net: bridge: vlan: add mcast snooping control include/uapi/linux/if_bridge.h | 18 + net/bridge/br.c | 9 +- net/bridge/br_device.c | 14 +- net/bridge/br_forward.c | 7 +- net/bridge/br_input.c | 17 +- net/bridge/br_mdb.c | 64 +- net/bridge/br_multicast.c | 1656 ++++++++++++++++++----------- net/bridge/br_multicast_eht.c | 92 +- net/bridge/br_netlink.c | 41 +- net/bridge/br_private.h | 355 +++++-- net/bridge/br_private_mcast_eht.h | 3 +- net/bridge/br_sysfs_br.c | 38 +- net/bridge/br_sysfs_if.c | 2 +- net/bridge/br_vlan.c | 85 +- net/bridge/br_vlan_options.c | 216 ++++ 15 files changed, 1791 insertions(+), 826 deletions(-) -- 2.31.1
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <razor@blackwall.org> To: netdev@vger.kernel.org Cc: bridge@lists.linux-foundation.org, Nikolay Aleksandrov <nikolay@nvidia.com>, roopa@nvidia.com Subject: [Bridge] [PATCH net-next 00/15] net: bridge: multicast: add vlan support Date: Mon, 19 Jul 2021 20:06:22 +0300 [thread overview] Message-ID: <20210719170637.435541-1-razor@blackwall.org> (raw) From: Nikolay Aleksandrov <nikolay@nvidia.com> Hi all, This patchset adds initial per-vlan multicast support, most of the code deals with moving to multicast context pointers from bridge/port pointers. That allows us to switch them with the per-vlan contexts when a multicast packet is being processed and vlan multicast snooping has been enabled. That is controlled by a global bridge option added in patch 06 which is off by default (BR_BOOLOPT_MCAST_VLAN_SNOOPING). It is important to note that this option can change only under RTNL and doesn't require multicast_lock, so we need to be careful when retrieving mcast contexts in parallel. For packet processing they are switched only once in br_multicast_rcv() and then used until the packet has been processed. For the most part we need these contexts only to read config values and check if they are disabled. The global mcast state which is maintained consists of querier and router timers, the rest are config options. The port mcast state which is maintained consists of query timer and link to router port list if it's ever marked as a router port. Port multicast contexts _must_ be used only with their respective global contexts, that is a bridge port's mcast context must be used only with bridge's global mcast context and a vlan/port's mcast context must be used only with that vlan's global mcast context due to the router port lists. This way a bridge port can be marked as a router in multiple vlans, but might not be a router in some other vlan. Also this allows us to have per-vlan querier elections, per-vlan queries and basically the whole multicast state becomes per-vlan when the option is enabled. One of the hardest parts is synchronization with vlan's memory management, that is done through a new vlan flag: BR_VLFLAG_MCAST_ENABLED which is changed only under multicast_lock. When a vlan is being destroyed first that flag is removed under the lock, then the multicast context is torn down which includes waiting for any outstanding context timers. Since all of the vlan processing depends on BR_VLFLAG_MCAST_ENABLED it must be checked first if the contexts are vlan and the multicast_lock has been acquired. That is done by all IGMP/MLD packet processing functions and timers. When processing a packet we have RCU so the vlan memory won't be freed, but if the flag is missing we must not process it. The timers are synchronized in the same way with the addition of waiting for them to finish in case they are running after removing the flag under multicast_lock (i.e. they were waiting for the lock). Multicast vlan snooping requires vlan filtering to be enabled, if it's disabled then snooping gets automatically disabled, too. BR_VLFLAG_GLOBAL_MCAST_ENABLED controls if a vlan has BR_VLFLAG_MCAST_ENABLED set which is used in all vlan disabled checks. We need both flags because one is controlled by user-space globally (BR_VLFLAG_GLOBAL_MCAST_ENABLED) and the other is for a particular bridge/vlan or port/vlan entry (BR_VLFLAG_MCAST_ENABLED). Since the latter is also used for synchronization between the multicast and vlan code, and also controlled by BR_VLFLAG_GLOBAL_MCAST_ENABLED we rely on it when checking if a vlan context is disabled. The multicast fast-path has 3 new bit tests on the cache-hot bridge flags field, I didn't observe any measurable difference. I haven't forced either context options to be always disabled when the other type is enabled because the state consists of timers which either expire (router) or don't affect the normal operation. Some options, like the mcast querier one, won't be allowed to change for the disabled context type, that will come with a future patch-set which adds per-vlan querier control. Another important addition is the global vlan options, so far we had only per bridge/port vlan options but in order to control vlan multicast snooping globally we need to add a new type of global vlan options. They can be changed only on the bridge device and are dumped only when a special flag is set in the dump request. The first global option is vlan mcast snooping control, it controls the vlan BR_VLFLAG_GLOBAL_MCAST_ENABLED private flag. It can be set only on master vlan entries. There will be many more global vlan options in the future both for multicast config and other per-vlan options (e.g. STP). There's a lot of room for improvements, I'll do some of the initial ones but splitting the state to different contexts opens the door for a lot more. Also any new multicast options become vlan-supported with very little to no effort by using the same contexts. Short patch description: patches 01-04: initial mcast context add, no functional changes patch 05: adds vlan mcast init and control helpers and uses them on vlan create/destroy patch 06: adds a global bridge mcast vlan snooping knob (default off) patches 07-08: add a helper for users which must derive the contexts based on current bridge and vlan options (e.g. timers) patch 09: adds checks for disabled vlan contexts in packet processing and timers patch 10: adds support for per-vlan querier and tagged queries patch 11: adds router port vlan id in the notifications patches 12-14: add global vlan options support (change, dump, notify) patch 15: adds per-vlan global mcast snooping control Future patch-sets which build on this one (in order): - vlan state mcast handling - user-space mdb contexts (currently only the bridge contexts are used there) - all bridge multicast config options added per-vlan global and per vlan/port - iproute2 support for all the new uAPIs - selftests This set has been stress-tested (deleting/adding ports/vlans while changing vlan mcast snooping while processing IGMP/MLD packets), and also has passed all bridge self-tests. I'm sending this set as early as possible since there're a few more related sets that should go in the same release to get proper and full mcast vlan snooping support. Thanks, Nik Nikolay Aleksandrov (15): net: bridge: multicast: factor out port multicast context net: bridge: multicast: factor out bridge multicast context net: bridge: multicast: use multicast contexts instead of bridge or port net: bridge: vlan: add global and per-port multicast context net: bridge: multicast: add vlan state initialization and control net: bridge: add vlan mcast snooping knob net: bridge: multicast: add helper to get port mcast context from port group net: bridge: multicast: use the port group to port context helper net: bridge: multicast: check if should use vlan mcast ctx net: bridge: multicast: add vlan querier and query support net: bridge: multicast: include router port vlan id in notifications net: bridge: vlan: add support for global options net: bridge: vlan: add support for dumping global vlan options net: bridge: vlan: notify when global options change net: bridge: vlan: add mcast snooping control include/uapi/linux/if_bridge.h | 18 + net/bridge/br.c | 9 +- net/bridge/br_device.c | 14 +- net/bridge/br_forward.c | 7 +- net/bridge/br_input.c | 17 +- net/bridge/br_mdb.c | 64 +- net/bridge/br_multicast.c | 1656 ++++++++++++++++++----------- net/bridge/br_multicast_eht.c | 92 +- net/bridge/br_netlink.c | 41 +- net/bridge/br_private.h | 355 +++++-- net/bridge/br_private_mcast_eht.h | 3 +- net/bridge/br_sysfs_br.c | 38 +- net/bridge/br_sysfs_if.c | 2 +- net/bridge/br_vlan.c | 85 +- net/bridge/br_vlan_options.c | 216 ++++ 15 files changed, 1791 insertions(+), 826 deletions(-) -- 2.31.1
next reply other threads:[~2021-07-19 17:22 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-19 17:06 Nikolay Aleksandrov [this message] 2021-07-19 17:06 ` [Bridge] [PATCH net-next 00/15] net: bridge: multicast: add vlan support Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 01/15] net: bridge: multicast: factor out port multicast context Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 02/15] net: bridge: multicast: factor out bridge " Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 03/15] net: bridge: multicast: use multicast contexts instead of bridge or port Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 04/15] net: bridge: vlan: add global and per-port multicast context Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 05/15] net: bridge: multicast: add vlan state initialization and control Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 06/15] net: bridge: add vlan mcast snooping knob Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 07/15] net: bridge: multicast: add helper to get port mcast context from port group Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 08/15] net: bridge: multicast: use the port group to port context helper Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 09/15] net: bridge: multicast: check if should use vlan mcast ctx Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 10/15] net: bridge: multicast: add vlan querier and query support Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 11/15] net: bridge: multicast: include router port vlan id in notifications Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 12/15] net: bridge: vlan: add support for global options Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 13/15] net: bridge: vlan: add support for dumping global vlan options Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 14/15] net: bridge: vlan: notify when global options change Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-19 17:06 ` [PATCH net-next 15/15] net: bridge: vlan: add mcast snooping control Nikolay Aleksandrov 2021-07-19 17:06 ` [Bridge] " Nikolay Aleksandrov 2021-07-20 13:30 ` [PATCH net-next 00/15] net: bridge: multicast: add vlan support patchwork-bot+netdevbpf 2021-07-20 13:30 ` [Bridge] " patchwork-bot+netdevbpf 2021-08-19 16:01 ` Joachim Wiberg 2021-08-19 16:01 ` [Bridge] " Joachim Wiberg 2021-08-19 16:22 ` Nikolay Aleksandrov 2021-08-19 16:22 ` [Bridge] " Nikolay Aleksandrov 2021-08-20 6:26 ` Joachim Wiberg 2021-08-20 6:26 ` [Bridge] " Joachim Wiberg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210719170637.435541-1-razor@blackwall.org \ --to=razor@blackwall.org \ --cc=bridge@lists.linux-foundation.org \ --cc=netdev@vger.kernel.org \ --cc=nikolay@nvidia.com \ --cc=roopa@nvidia.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.