Hi Andrew,
Andrew Lunn <and...@lunn.ch> writes:
>> > Then starts the work passing down to the hardware that the host has
>> > joined/left a group. The existing switchdev mdb object cannot be used,
>> > since the semantics are different. The existing
>> > SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
>> > group should be forwarded out that port of the switch. However here we
>> > require the exact opposite. We want multicast frames for the group
>> > received on the port to the forwarded to the host. Hence add a new
>> > object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to
>> > forward to the host. This new object is then propagated through the
>> > DSA layers. No DSA driver changes should be needed, this should just
>> > work...
>>
>> The patchset looks good. I would like to ask you some details though,
>> because I don't understand why the semantics are different.
>>
>> Technically, what happens is that an MDB entry is programmed on the
>> bridge interface. From the _bridge point of view_, there is no technical
>> difference as in programming an MDB entry on a bridged port. Correct?
>
> It is not quite as simple as that. Image:
>
> brctl addbr br0
> brctl addif br0 eth2
> brctl addif br0 lan0
>
> where eth2 is just a regular ethernet interface. Say there is a join
> received on eth2 for group 224.42.42.42. The IGMP snooping code in the
> software bridge then needs to tell lan0 to forward all multicast
> traffic for 224.42.42.42 to the software bridge, so it can forward it
> to eth2. The br0 interface is not involved.
>
> Now, my patchset is not implementing this use case. But at some point,
> we probably will want to implement it. We want a generic switchdev API
> which says forward all the traffic for a group to the host. The host
> will then decide what to do with it.
>
> Now, your suggestion would be to pass br0 for the use case i'm
> implementing here. And we could pass eth2 for the above use cases. But
> for the hardware offload, it does not matter what interface the frames
> are heading towards. All the offload needs to know is that the host
> software bridge wants the frames.
I do understand a bit more. So when an MDB entry is programmed on a
bridge port, all we need to do is program the dedicated CPU port of a
switch port if the target bridge port isn't the switch port.
Something like:
// the bridge code sends this mdb object:
struct switchdev_obj_port_mdb mdb = { .orig_dev = eth2, .dev = lan0 }
// the DSA code receives it:
/* if the switch port isn't the target port, program its CPU port */
dp = dsa_slave_to_port(mdb->dev)
if (mdb->dev != mdb->orig_dev)
dp = dp->cpu_dp;
dsa_port_mdb_add(dp, mdb);
Doesn't this cover your use cases?
Thanks,
Vivien
