[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22c022da-4b1d-b0fe-b701-ce2163b3c3c0@cumulusnetworks.com>
Date: Wed, 2 Sep 2020 23:17:46 +0300
From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, roopa@...dia.com,
bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next v2 00/15] net: bridge: mcast: initial IGMPv3
support (part 1)
On 9/2/20 11:08 PM, Nikolay Aleksandrov wrote:
> On 9/2/20 10:58 PM, David Miller wrote:
>> From: Nikolay Aleksandrov <nikolay@...ulusnetworks.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.
Powered by blists - more mailing lists