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
