Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 19 Jul 2021 20:06:22 +0300 you wrote:
> From: Nikolay Aleksandrov <nikolay@xxxxxxxxxx>
>
> 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.
>
> [...]
Here is the summary with links:
- [net-next,01/15] net: bridge: multicast: factor out port multicast context
https://git.kernel.org/netdev/net-next/c/9632233e7de8
- [net-next,02/15] net: bridge: multicast: factor out bridge multicast context
https://git.kernel.org/netdev/net-next/c/d3d065c0032b
- [net-next,03/15] net: bridge: multicast: use multicast contexts instead of bridge or port
https://git.kernel.org/netdev/net-next/c/adc47037a7d5
- [net-next,04/15] net: bridge: vlan: add global and per-port multicast context
https://git.kernel.org/netdev/net-next/c/613d61dbef8e
- [net-next,05/15] net: bridge: multicast: add vlan state initialization and control
https://git.kernel.org/netdev/net-next/c/7b54aaaf53cb
- [net-next,06/15] net: bridge: add vlan mcast snooping knob
https://git.kernel.org/netdev/net-next/c/f4b7002a7076
- [net-next,07/15] net: bridge: multicast: add helper to get port mcast context from port group
https://git.kernel.org/netdev/net-next/c/74edfd483de8
- [net-next,08/15] net: bridge: multicast: use the port group to port context helper
https://git.kernel.org/netdev/net-next/c/eb1593a0b4c4
- [net-next,09/15] net: bridge: multicast: check if should use vlan mcast ctx
https://git.kernel.org/netdev/net-next/c/4cdd0d10f31d
- [net-next,10/15] net: bridge: multicast: add vlan querier and query support
https://git.kernel.org/netdev/net-next/c/615cc23e6283
- [net-next,11/15] net: bridge: multicast: include router port vlan id in notifications
https://git.kernel.org/netdev/net-next/c/1e9ca45662d6
- [net-next,12/15] net: bridge: vlan: add support for global options
https://git.kernel.org/netdev/net-next/c/47ecd2dbd8ec
- [net-next,13/15] net: bridge: vlan: add support for dumping global vlan options
https://git.kernel.org/netdev/net-next/c/743a53d9636a
- [net-next,14/15] net: bridge: vlan: notify when global options change
https://git.kernel.org/netdev/net-next/c/9aba624d7cb2
- [net-next,15/15] net: bridge: vlan: add mcast snooping control
https://git.kernel.org/netdev/net-next/c/9dee572c3848
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
