netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: 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: Tue, 22 Jan 2019 15:12:41 +0200	[thread overview]
Message-ID: <20190122131239.GC3125@khorivan> (raw)
In-Reply-To: <4cf42ef9-7136-15ff-1244-1d946acd07ae@gmail.com>

On Mon, Jan 21, 2019 at 03:37:41PM -0800, Florian Fainelli wrote:
>On 12/4/18 3:42 PM, Ivan Khoronzhuk wrote:
>> On Tue, Dec 04, 2018 at 11:49:27AM -0800, Florian Fainelli wrote:

[...]

>
>Ivan, based on the recent submission I copied you on [1], it sounds like
>we want to move ahead with your proposal to extend netdev_hw_addr with a
>vid member.
>
>On second thought, your approach is good and if we enclose the vid
>member within an #if IS_ENABLED(CONFIG_VLAN)8021Q) we should be good for
>most foreseeable use cases, if not, we can always introduce a variable
>size/defined context in the future.
>
>Can you resubmit this patch series as non-RFC in the next few days so I
>can also repost mine [1] and take advantage of these changes for
>multicast over VLAN when VLAN filtering is globally enabled on the device.
>
>[1]: https://www.spinics.net/lists/netdev/msg544722.html
>
>Thanks!

Yes, sure. I can start to do that in several days.
Just a little busy right now.

Just before doing this, maybe some comments could be added as it has more
attention now. Meanwhile I can send alternative variant but based on
real dev splitting addresses between vlans. In this approach it leaves address
space w/o vid extension but requires more changes to vlan core. Drawback here
that to change one address alg traverses all related vlan addresses, it can be
cpu/time wasteful, if it's done regularly, but saves memory....

Basically it's implemented locally in cpsw and requires more changes to move
it as some vlan core auxiliary functions to be reused. But it can work only
with vlans directly on top of real dev, which is fixable.

Core function here:
__hw_addr_ref_sync_dev
it is called only for address the link of which was increased/decreased, thus
update made only on one address, comparing it for every vlan dev.

It was added with this patch:
[1] net: core: dev_addr_lists: add auxiliary func to handle reference address 
update e7946760de5852f32

And used by this patch:
[2] net: ethernet: ti: cpsw: fix vlan mcast 15180eca569bfe1d4d

So, idea is to move [2] to be vlan core auxiliary function to be reused
by NIC drivers.

But potentially it can bring a little more changes I assume:

1) add priv_flag |= IFF_IV_FLT (independent vlan filtering). It allows to reuse
this flag for farther changes, probably for per vlan allmulti or so.

2) real dev has to have complete list for vlans, not only their vids, but also
all vlandevs in device chain above it. So changes in add_vid can be required.
Vlan core can assign vlan dev pointer to real device only after it's completely
initialized. And for propagation reasons it requires every device in
infrastructure to be aware. That seems doable, but depends not only on me.

3) Move code from [2] to be auxiliary vlan core API for setting mc and uc.
From this patch only one function is cpsw specific: cpsw_set_mc(). The rest can
be applicable on every NIC supporting IFF_IV_FLT.

4) Move code from link below to do the same but for uc addresses:
https://git.linaro.org/people/ivan.khoronzhuk/tsn_kernel.git/commit/?h=ucast_vlan_fix&id=ebc88a7d8758759322d9ff88f25f8bac51ce7219
here only one func cpsw specific: cpsw_set_uc()
the rest can be generic.

As third alternative, we can think about how to reduce memory for addresses by
reusing them or else, but this is as continuation of addr+vid approach, and API
probably would be the same.

Then all this can be compared for proper decision.

>-- 
>Florian

-- 
Regards,
Ivan Khoronzhuk

  reply	other threads:[~2019-01-22 13:12 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 [this message]
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
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=20190122131239.GC3125@khorivan \
    --to=ivan.khoronzhuk@linaro.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --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).