On Mon, Oct 06, 2025 at 11:43:02AM -0400, Huang, Joseph wrote:

On 10/4/2025 10:27 AM, Linus Lüssing wrote:

quoted

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?

quoted

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.