On Fri, Jul 26, 2019 at 02:02:15PM +0200, Horatiu Vultur wrote: > Hi Nikolay, > > The 07/26/2019 12:26, Nikolay Aleksandrov wrote: > > External E-Mail > > > > > > On 26/07/2019 11:41, Nikolay Aleksandrov wrote: > > > On 25/07/2019 17:21, Horatiu Vultur wrote: > > >> Hi Nikolay, > > >> > > >> The 07/25/2019 16:21, Nikolay Aleksandrov wrote: > > >>> External E-Mail > > >>> > > >>> > > >>> On 25/07/2019 16:06, Nikolay Aleksandrov wrote: > > >>>> On 25/07/2019 14:44, Horatiu Vultur wrote: > > >>>>> There is no way to configure the bridge, to receive only specific link > > >>>>> layer multicast addresses. From the description of the command 'bridge > > >>>>> fdb append' is supposed to do that, but there was no way to notify the > > >>>>> network driver that the bridge joined a group, because LLADDR was added > > >>>>> to the unicast netdev_hw_addr_list. > > >>>>> > > >>>>> Therefore update fdb_add_entry to check if the NLM_F_APPEND flag is set > > >>>>> and if the source is NULL, which represent the bridge itself. Then add > > >>>>> address to multicast netdev_hw_addr_list for each bridge interfaces. > > >>>>> And then the .ndo_set_rx_mode function on the driver is called. To notify > > >>>>> the driver that the list of multicast mac addresses changed. > > >>>>> > > >>>>> Signed-off-by: Horatiu Vultur <horatiu.vultur@xxxxxxxxxxxxx> > > >>>>> --- > > >>>>> net/bridge/br_fdb.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++--- > > >>>>> 1 file changed, 46 insertions(+), 3 deletions(-) > > >>>>> > > >>>> > > >>>> Hi, > > >>>> I'm sorry but this patch is wrong on many levels, some notes below. In general > > >>>> NLM_F_APPEND is only used in vxlan, the bridge does not handle that flag at all. > > >>>> FDB is only for *unicast*, nothing is joined and no multicast should be used with fdbs. > > >>>> MDB is used for multicast handling, but both of these are used for forwarding. > > >>>> The reason the static fdbs are added to the filter is for non-promisc ports, so they can > > >>>> receive traffic destined for these FDBs for forwarding. > > >>>> If you'd like to join any multicast group please use the standard way, if you'd like to join > > >>>> it only on a specific port - join it only on that port (or ports) and the bridge and you'll > > >>> > > >>> And obviously this is for the case where you're not enabling port promisc mode (non-default). > > >>> In general you'll only need to join the group on the bridge to receive traffic for it > > >>> or add it as an mdb entry to forward it. > > >>> > > >>>> have the effect that you're describing. What do you mean there's no way ? > > >> > > >> Thanks for the explanation. > > >> There are few things that are not 100% clear to me and maybe you can > > >> explain them, not to go totally in the wrong direction. Currently I am > > >> writing a network driver on which I added switchdev support. Then I was > > >> looking for a way to configure the network driver to copy link layer > > >> multicast address to the CPU port. > > >> > > >> If I am using bridge mdb I can do it only for IP multicast addreses, > > >> but how should I do it if I want non IP frames with link layer multicast > > >> address to be copy to CPU? For example: all frames with multicast > > >> address '01-21-6C-00-00-01' to be copy to CPU. What is the user space > > >> command for that? > > >> > > > > > > Check SIOCADDMULTI (ip maddr from iproute2), f.e. add that mac to the port > > > which needs to receive it and the bridge will send it up automatically since > > > it's unknown mcast (note that if there's a querier, you'll have to make the > > > bridge mcast router if it is not the querier itself). It would also flood it to all > > > > Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This > > traffic will always be flooded by the bridge (and also a copy will be locally sent up). > > Thus only the flooding may need to be controlled. > > OK, I see, but the part which is not clear to me is, which bridge > command(from iproute2) to use so the bridge would notify the network > driver(using swichdev or not) to configure the HW to copy all the frames > with dmac '01-21-6C-00-00-01' to CPU? So that the bridge can receive > those frames and then just to pass them up. Hi Horatiu Something to keep in mind. My default, multicast should be flooded, and that includes the CPU port for a DSA driver. Adding an MDB entry allows for optimisations, limiting which ports a multicast frame goes out of. But it is just an optimisation. Andrew
