[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM3PR11MB873600D47EA64FF199EF0FE0ECE52@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Sat, 18 Jan 2025 00:49:10 +0000
From: <Tristram.Ha@...rochip.com>
To: <tharvey@...eworks.com>
CC: <Arun.Ramadoss@...rochip.com>, <andrew@...n.ch>, <davem@...emloft.net>,
<olteanv@...il.com>, <Woojung.Huh@...rochip.com>,
<linux-kernel@...r.kernel.org>, <pabeni@...hat.com>,
<netdev@...r.kernel.org>, <edumazet@...gle.com>,
<UNGLinuxDriver@...rochip.com>, <kuba@...nel.org>
Subject: RE: [PATCH net] net: dsa: microchip: ksz9477: fix multicast filtering
> Hi Tristram,
>
> Thanks for your feedback.
>
> What is the behavior when the reserved multicast table is not enabled
> (does it forward to all ports, drop all mcast, something else?)
>
> > The default reserved multicast table forwards to host port on entries 0,
> > 2, and 6; skips host port on entries 4, 5, and 7; forwards to all ports
> > on entry 3; and drops on entry 1.
> >
>
> Is this behavior the desired behavior as far as the Linux DSA folks would want?
>
> commit 331d64f752bb ("net: dsa: microchip: add the enable_stp_addr
> pointer in ksz_dev_ops") enables the reserved multicast table and
> adjusts the cpu port for entry 0 leaving the rest the same (and wrong
> if the cpu port is not the highest port in the switch).
>
> My patch adjusts the entries but keeps the rules the same and the
> question that is posed is that the right thing to do with respect to
> Linux DSA?
When reserved multicast address table is not enabled the multicast
forwarding follows the standard operation which is broadcast to all
ports.
Note KSZ9477 and LAN937X are able to program multicast forwarding in
either static or dynamic MAC table with high entry count, so it is
probably best to not use the reserved multicast address table and let the
DSA stack program each multicast address individually.
Powered by blists - more mailing lists