Re: [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for uc and mc address lists

[Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>]

On Tue, Jan 08, 2019 at 10:21:25AM -0800, Florian Fainelli wrote:
>On 1/7/19 9:01 PM, Florian Fainelli wrote:
>> Le 12/4/18 à 4:04 PM, Ivan Khoronzhuk a écrit :
>>> On Tue, Dec 04, 2018 at 11:49:27AM -0800, Florian Fainelli wrote:
>>>
>>> ...
>>>
>>>>>
>>>>> I was thinking also about pinned list of vlans to the address, but in
>>>>> this case this information also has to be synced by members of device
>>>>> chain,
>>>>> because it can be modified on any device level and it looks not very
>>>>> friendly,
>>>>> and at the end address space has addresses with pinned lists of vlans
>>>>> with
>>>>> their pointers. But keeping this stuff in sync is not simplest decision.
>>>>>
>>>>>
>>>>
>>>> I really think we are not communicating properly, it really seems to me
>>>> that if you had the information about the upper device trying to add an
>>>> address to the lower device filter's either through notification or call
>>>> to ndo_set_rxmode, you could be solving your problems. What are we
>>>> missing here?
>>>
>>> Sry, missed this one. The problem in getting  the owner of address.
>>> Just simple case: vlan/macvlan/real_dev or vlan/.../.../real_dev
>>>
>>> The real dev hasn't simple way to get vid the address belong to, or it has?
>>
>> Humm looks like your right, by the time the address lists are
>> synchronized (e.g: from = vlan_dev, to = real_dev), we lost that
>> information. It looks like I just managed to find such an use case
>> myself with VLAN filtering enabled on a bridge (so switch is VLAN aware)
>> and a VLAN device created on the bridge (br0.42) but with IGMP snooping
>> turned off (so we don't get HOST_MDB notifications with correct VLAN ID).
>>
>> Maybe keeping the "from" net_device within the address list that is
>> processed by ndo_set_rx_mode() will do the job though?
>>
>> Then you can do things like:
>>
>> if (is_vlan_dev(ha->dev) && ha->dev != dev)
>> 	vid = vlan_dev_vlan_id(ha->dev);
>>
>> and it should scale to any type of stacked device, regardless of VID or
>> something else that we need?
>>
>> Can you remind me of your use case again? Is it because your switch has
>> VLAN filtering enabled and you need to make sure that MC addresses on
>> VLAN device get programmed into the switch's multicast database with
>> correct VID?
>
>Ivan, can you see if the following would work for you:
>
>https://github.com/ffainelli/linux/commit/19e173ebdcdd32f5f5b5ef29049e35d33ad058f2
>
>this should be more scalable approach in that we can support HOST_MDB
>notifications from the bridge, the same way we would get notified about
>IGMP snooping from the bridge and this does not impact any other driver
>than those that elect to receive switchdev object notifications, which
>cpsw should really implement by now...

Sorry missed 2 last comments and seems like it's clear now.
I need to be in TO or CC list my filters can parse it, probably I need
to create more smart filters.

>-- 
>Florian

-- 
Regards,
Ivan Khoronzhuk