On Thu, Nov 09, 2017 at 10:13:15PM +0100, Andrew Lunn wrote:

On Thu, Nov 09, 2017 at 12:35:32PM -0800, Florian Fainelli wrote:

quoted

+Ido, Jiri,

On 11/09/2017 12:21 PM, Andrew Lunn wrote:

quoted

On Thu, Nov 09, 2017 at 11:38:26AM -0800, Florian Fainelli wrote:

quoted

On 11/09/2017 11:30 AM, Andrew Lunn wrote:

quoted

quoted

This means that switchdev drivers won't ever have to treat a HOST_MDB
notification any differently than a PORT_MDB notification

No, they need to treat it very differently. 

Allow me to rephrase, switchdev drivers will ignore HOST_MDB
notifications because that does not resolve to something they can do
something about.

Hi Florian

Yes, they can. In fact, if they want to support IGMP snooping on the
bridge interface, they have to. How else do they know to forward
traffic to the host?

On a switchdev fabric, you need to have at least one user-facing port be
a member of the bridge, and when the switchdev driver configures that,
it should just make the IGMP packets trap to the management interface
such that they can be delivered from the port member to the bridge
network device (br0). In that case, I don't really see why you would
need to send a HOST_MDB message to a switchdev fabric, since that should
be part of enslaving the port to the bridge in the first place and
appropriately configure the management interface to get IGMP snooping,
BDPU etc.

So your network is carrying gigabits of multicast traffic. Are you
saying it should all hit the host, so the bridge can throw it away?
No, it is much more efficient that the bridge tells the switch when it
is interested in a specific multicast group. I.e. it sends a HOST_MDB
request for the group. Only then will the switch start to send the
data for that group to the host.

Yep. We already have support for marking br0 as router port which means
the bridge driver will get both unregistered multicast packets and
packets hitting mdb entries. With your patch, we'll need to add the
ability to get only packets hitting a specific mdb entry which should be
trivial enough.

Florian, you're right that by default IGMP (control) packets are trapped
to the bridge driver, but Andrew's set adds the ability to trap the
_data_ packets hitting a specific mdb entry.