[Bridge] [PATCH net-next v2 00/15] net: bridge: mcast: initial IGMPv3 support (part 1)

Nikolay Aleksandrov nikolay at cumulusnetworks.com
Wed Sep 2 20:08:40 UTC 2020


On 9/2/20 10:58 PM, David Miller wrote:
> From: Nikolay Aleksandrov <nikolay at 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.





More information about the Bridge mailing list