Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches

[Florian Fainelli <f.fainelli@gmail.com>]

On 11/1/2020 8:13 AM, Vladimir Oltean wrote:
> On Sun, Nov 01, 2020 at 05:39:06PM +0200, Ido Schimmel wrote:
>> You also wondered which indication you would get down to the driver that
>> eventually needs to program the hardware to get the packets:
>>
>> "Who will notify me of these multicast addresses if I'm bridged and I
>> need to terminate L2 or L4 PTP through the data path of the slave
>> interfaces and not of the bridge."
>>
>> Which kernel entity you want to get the notification from? The packet
>> socket wants the packets, so it should notify you. The kernel is aware
>> that traffic is offloaded and can do whatever it needs (e.g., calling
>> the ndo) in order to extract packets from the hardware data path to the
>> CPU and to the socket.
> 
> Honestly, just as I was saying, I was thinking about using the
> dev_mc_add call that is emitted today, and simply auditing the
> dev_mc_add and dev_uc_add calls which are unnecessary (like in the case
> of non-automatic bridge interfaces), for example like this:
> 
> if (!(dev->features & NETIF_F_PROMISC_BY_DEFAULT))
> 	dev_uc_add(dev, static bridge fdb entry);
> 
> To me this would be the least painful way forward.

Vladimir, what do you think about re-posting this series with the DSA
ports operating in standalone or bridge mode with the bridge being
multicast aware, and tackle the termination of PTP frames on DSA ports
being bridged separately?

From what I could read there does not appear to be a problem with doing
RX filtering for standalone ports since we all agree that these
net_device should look like a regular NIC port with RX filtering capability.
-- 
Florian