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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux