Re: [PATCH net] net: bridge: Trigger host query on v6 addr valid

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Oct 06, 2025 at 11:43:02AM -0400, Huang, Joseph wrote:
> On 10/4/2025 10:27 AM, Linus Lüssing wrote:
> > However (at least for a non-hardware-offloaded) bridge as far as I
> > recall this shouldn't create any multicast packet loss and should
> > operate as "normal" with flooding multicast data packets first,
> > with multicast snooping activating on multicast data
> > after another IGMP/MLD querier interval has elapsed (default:
> > 125 sec.)?

Isn't this 10 seconds (default mcast_query_response_interval)?

BTW, I see that delay_timer is started in br_multicast_set_querier()
which is called from br_changelink(). Isn't this problematic if querier
is enabled while the bridge is administratively down? It's possible for
this timer to expire by the time the bridge is opened.

> Some systems could not afford to flood multicast traffic. Think of some
> resource-constrained low power sensors connected to a network with high
> volume multicast video traffic for example. The multicast traffic could
> easily choke the sensors and is essentially a DDoS attack.

Note that even with your patch (or optimistic DAD) there will still be a
time period where multicast traffic is flooded to give responses enough
time to arrive.

Can you clarify how you observed the problem? Did you observe packet
loss with hardware offload or did you observe excessive flooding with
the software data path?

> > Which indeed could be optimized and is confusing, this delay could
> > be avoided. Is that that the issue you mean, Joseph?
> > (I'd consider it more an optimization, so for net-next, not
> > net though.)
> > 
> 
> I'm not sure this should be categorized as an optimization. If we never
> intend to send Startup Queries, that's a different story. But if we intend
> to send it but failed, I think that should be a bug.

I would say that the deciding factor should be if it's a regression or
not.