| Message ID | 20200902112529.1570040-1-nikolay@cumulusnetworks.com |
|---|---|
| Headers | show |
| Series | net: bridge: mcast: initial IGMPv3 support (part 1) | expand |
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Date: Wed, 2 Sep 2020 14:25:14 +0300 > Here're the sets that will come next (in order): > - Fast path patch-set which adds support for (S, G) mdb entries needed > for IGMPv3 forwarding, entry add source (kernel, user-space etc) > needed for IGMPv3 entry management, entry block mode needed for > IGMPv3 exclude mode. This set will also add iproute2 support for > manipulating and showing all the new state. > - Selftests patch-set which will verify all IGMPv3 state transitions > and forwarding > - Explicit host tracking patch-set, needed for proper fast leave and > with it fast leave will be enabled for IGMPv3 > > Not implemented yet: > - Host IGMPv3 support (currently we handle only join/leave as before) > - Proper other querier source timer and value updates > - IGMPv3/v2 compat (I have a few rough patches for this one) What about ipv6 support? The first thing I notice when reading these patches is the source filter code only supports ipv4.
On 9/2/20 10:58 PM, David Miller wrote: > From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> > Date: Wed, 2 Sep 2020 14:25:14 +0300 > >> Here're the sets that will come next (in order): >> - Fast path patch-set which adds support for (S, G) mdb entries needed >> for IGMPv3 forwarding, entry add source (kernel, user-space etc) >> needed for IGMPv3 entry management, entry block mode needed for >> IGMPv3 exclude mode. This set will also add iproute2 support for >> manipulating and showing all the new state. >> - Selftests patch-set which will verify all IGMPv3 state transitions >> and forwarding >> - Explicit host tracking patch-set, needed for proper fast leave and >> with it fast leave will be enabled for IGMPv3 >> >> Not implemented yet: >> - Host IGMPv3 support (currently we handle only join/leave as before) >> - Proper other querier source timer and value updates >> - IGMPv3/v2 compat (I have a few rough patches for this one) > > What about ipv6 support? The first thing I notice when reading these > patches is the source filter code only supports ipv4. > Indeed, these are IGMPv3/IPv4 targeted. But MLDv2 should be relatively easy to add once we have all the set/state transitions as it uses the same. Adding both at once would be a much bigger change. Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should be a much easier change, but I must admit given the amount of work this required I haven't yet looked into MLDv2 in details. The majority of the changes would be just switch protocol statements that take care of the IPv6 part. I have also explicitly added the IPv4 checks right now to limit the dump code, otherwise we'd get for example group mode export for IPv6 entries which yet don't support it. If you'd prefer I can remove the explicit IPv4 checks and leave the switch protocol check with ETH_P_IP only currently, but it wouldn't affect the end result much.
On 9/2/20 11:08 PM, Nikolay Aleksandrov wrote: > On 9/2/20 10:58 PM, David Miller wrote: >> From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> >> Date: Wed, 2 Sep 2020 14:25:14 +0300 >> >>> Here're the sets that will come next (in order): >>> - Fast path patch-set which adds support for (S, G) mdb entries needed >>> for IGMPv3 forwarding, entry add source (kernel, user-space etc) >>> needed for IGMPv3 entry management, entry block mode needed for >>> IGMPv3 exclude mode. This set will also add iproute2 support for >>> manipulating and showing all the new state. >>> - Selftests patch-set which will verify all IGMPv3 state transitions >>> and forwarding >>> - Explicit host tracking patch-set, needed for proper fast leave and >>> with it fast leave will be enabled for IGMPv3 >>> >>> Not implemented yet: >>> - Host IGMPv3 support (currently we handle only join/leave as before) >>> - Proper other querier source timer and value updates >>> - IGMPv3/v2 compat (I have a few rough patches for this one) >> >> What about ipv6 support? The first thing I notice when reading these >> patches is the source filter code only supports ipv4. >> > > Indeed, these are IGMPv3/IPv4 targeted. But MLDv2 should be relatively easy to > add once we have all the set/state transitions as it uses the same. > Adding both at once would be a much bigger change. > > Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should be a much > easier change, but I must admit given the amount of work this required I haven't > yet looked into MLDv2 in details. The majority of the changes would be just switch > protocol statements that take care of the IPv6 part. > > I have also explicitly added the IPv4 checks right now to limit the dump code, otherwise > we'd get for example group mode export for IPv6 entries which yet don't support it. > > If you'd prefer I can remove the explicit IPv4 checks and leave the switch protocol check > with ETH_P_IP only currently, but it wouldn't affect the end result much. i. e. this doesn't exclude IPv6 or makes it worse for it, on the contrary the ops needed to implement MLDv2 state transitions are in this set, they just need to be extended for v6. The new br_ip src group field contains also a field for an IPv6 address.
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Date: Wed, 2 Sep 2020 23:08:40 +0300 > Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should > be a much easier change, but I must admit given the amount of work > this required I haven't yet looked into MLDv2 in details. The > majority of the changes would be just switch protocol statements > that take care of the IPv6 part. As difficult as this is for me to do, I really have to be consistent in my policy and push back on this. We are far past the point of accepting new features without ipv6 support as well, sorry.
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Date: Wed, 2 Sep 2020 23:17:46 +0300 > i. e. this doesn't exclude IPv6 or makes it worse for it, on the > contrary the ops needed to > implement MLDv2 state transitions are in this set, they just need to > be extended for v6. > The new br_ip src group field contains also a field for an IPv6 > address. Great, then implement those parts and resubmit and we'll all be happy :-)
Hi all, This patch-set implements the control plane for initial IGMPv3 support which takes care of include/exclude sets and state transitions based on the different report types. Patch 01 arranges the structure better by moving the frequently used fields together, patches 02 and 03 add support for source lists and group modes per port group which are dumped. Patch 04 adds support for group-and-source specific queries required for IGMPv3. Patch 05 factors out the port group deletion code which is used in a few places, then patch 06 adds support for group and group-and-source query retransmissions via a new rexmit timer. Patches 07 and 08 make use of the already present mdb fill functions when sending notifications so we can have the full mdb entries' state filled in (with sources, mode etc). Patch 09 takes care of port group expiration, it switches the group mode to include and deletes it if there are no sources with active timers. Patches 10-13 are the core changes which add support for IGMPv3 reports and handle the source list set operations as per RFC 3376, all IGMPv3 report types with their transitions should be supported after these patches. I've used RFC 3376 and FRR as a reference implementation. The source lists are capped at 32 entries, we can remove that limitation at a later point which would require a better data structure to hold them. IGMPv3 processing is hidden behind the bridge's multicast_igmp_version option which must be set to 3 in order to enable it. Patch 14 improves other querier processing a bit (more about this below). And finally patch 15 transform the src gc so it can be used with all mcast objects since now we have multiple timers that can be running and we need to make sure they have all finished before freeing the objects. This is part 1, it only adds control plane support and doesn't change the fast path. A following patch-set will take care of that. Here're the sets that will come next (in order): - Fast path patch-set which adds support for (S, G) mdb entries needed for IGMPv3 forwarding, entry add source (kernel, user-space etc) needed for IGMPv3 entry management, entry block mode needed for IGMPv3 exclude mode. This set will also add iproute2 support for manipulating and showing all the new state. - Selftests patch-set which will verify all IGMPv3 state transitions and forwarding - Explicit host tracking patch-set, needed for proper fast leave and with it fast leave will be enabled for IGMPv3 Not implemented yet: - Host IGMPv3 support (currently we handle only join/leave as before) - Proper other querier source timer and value updates - IGMPv3/v2 compat (I have a few rough patches for this one) v2: patches 02-03: make src lists RCU friendly so they can be traversed when dumping, reduce limit to a more conservative 32 src group entries for a start patches 11-13: remove helper and directly do bitops patch 15: force mcast gc on bridge port del to make sure port group timers have finished before freeing the port Thanks, Nik Nikolay Aleksandrov (15): net: bridge: mdb: arrange internal structs so fast-path fields are close net: bridge: mcast: add support for group source list net: bridge: mcast: add support for src list and filter mode dumping net: bridge: mcast: add support for group-and-source specific queries net: bridge: mcast: factor out port group del net: bridge: mcast: add support for group query retransmit net: bridge: mdb: push notifications in __br_mdb_add/del net: bridge: mdb: use mdb and port entries in notifications net: bridge: mcast: delete expired port groups without srcs net: bridge: mcast: support for IGMPv3 IGMPV3_ALLOW_NEW_SOURCES report net: bridge: mcast: support for IGMPV3_MODE_IS_INCLUDE/EXCLUDE report net: bridge: mcast: support for IGMPV3_CHANGE_TO_INCLUDE/EXCLUDE report net: bridge: mcast: support for IGMPV3_BLOCK_OLD_SOURCES report net: bridge: mcast: improve v3 query processing net: bridge: mcast: destroy all entries via gc include/uapi/linux/if_bridge.h | 21 + net/bridge/br_mdb.c | 223 ++++--- net/bridge/br_multicast.c | 1040 +++++++++++++++++++++++++++++--- net/bridge/br_private.h | 67 +- 4 files changed, 1170 insertions(+), 181 deletions(-)