linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: davem@davemloft.net, linux-omap@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	jiri@mellanox.com, andrew@lunn.ch
Subject: Re: [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for uc and mc address lists
Date: Mon, 7 Jan 2019 21:01:25 -0800	[thread overview]
Message-ID: <1dd05b34-e275-d67c-df30-e3694d90e9cc@gmail.com> (raw)
In-Reply-To: <20181205000450.GB3507@khorivan>

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?
-- 
Florian

  reply	other threads:[~2019-01-08  5:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 18:40 [RFC PATCH net-next 0/5] net: allow hw addresses for virtual devices Ivan Khoronzhuk
2018-12-03 18:40 ` [RFC PATCH net-next 1/5] net: core: dev_addr_lists: add VID to device address space Ivan Khoronzhuk
2018-12-03 18:40 ` [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for uc and mc address lists Ivan Khoronzhuk
2018-12-03 22:17   ` Florian Fainelli
2018-12-03 23:51     ` Ivan Khoronzhuk
2018-12-03 23:57       ` Florian Fainelli
2018-12-04  1:32         ` Ivan Khoronzhuk
2018-12-04 18:57         ` Ivan Khoronzhuk
2018-12-04 19:49           ` Florian Fainelli
2018-12-04 23:42             ` Ivan Khoronzhuk
2019-01-21 23:37               ` Florian Fainelli
2019-01-22 13:12                 ` Ivan Khoronzhuk
2019-02-13 16:17                   ` Ivan Khoronzhuk
2019-02-14  4:49                     ` Florian Fainelli
2019-02-14 13:03                       ` Ivan Khoronzhuk
2018-12-05  0:04             ` Ivan Khoronzhuk
2019-01-08  5:01               ` Florian Fainelli [this message]
2019-01-08 18:21                 ` Florian Fainelli
2019-01-22 14:15                   ` Ivan Khoronzhuk
2018-12-03 18:40 ` [RFC PATCH net-next 3/5] net: 8021q: vlan_dev: add vid tag for vlan device mac address Ivan Khoronzhuk
2018-12-03 18:40 ` [RFC PATCH net-next 4/5] net: ethernet: add default vid len for all ehternet kind devices Ivan Khoronzhuk
2018-12-03 18:40 ` [RFC PATCH net-next 5/5] net: ethernet: ti: cpsw: update mc vlan and add uc vlan support based on addr vids Ivan Khoronzhuk
2018-12-03 22:25 ` [RFC PATCH net-next 0/5] net: allow hw addresses for virtual devices Florian Fainelli
2018-12-04  1:15   ` Ivan Khoronzhuk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dd05b34-e275-d67c-df30-e3694d90e9cc@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=jiri@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).