netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: dsahern@gmail.com
Cc: idosch@idosch.org, 3chas3@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH v4,net-next] vlan: implement vlan id and protocol changes
Date: Sun, 08 Jul 2018 10:47:44 +0900 (KST)	[thread overview]
Message-ID: <20180708.104744.768358766310806101.davem@davemloft.net> (raw)
In-Reply-To: <fd11c22b-64f3-d943-f820-832fb6d1c2bd@gmail.com>

From: David Ahern <dsahern@gmail.com>
Date: Sat, 7 Jul 2018 19:23:16 -0600

> On 7/7/18 7:14 AM, Ido Schimmel wrote:
>> On Sat, Jul 07, 2018 at 08:11:16PM +0900, David Miller wrote:
>>> Chas, it seems to me that you add the new notifier by not even one
>>> driver is listening for the event.
>>>
>>> Either it is necessary, and you should show at least one example
>>> use case, or it not necessary and therefore should not be added.
>> 
>> Chas, I'll take a look and send you a patch for mlxsw that you can fold
>> into your v5.
>> 
>> In the future, please Cc those who commented on earlier versions of your
>> patch.
> 
> What about the impacts to vlan devices enslaved to bridges?
> 
> What about neighbor entries? Shouldn't entries associated with prior
> device (vlan id) be removed?
> 
> I think in the end the idea of changing a vid or protocol for vlan
> device is the wrong thing to allow. I don't buy your response last time
> of "That's a lot of churn (netlink mesages, kernel calls) for something
> relatively simple." It's not a simple change.

I agree, there are so many things tied to the VLAN configuration.  And
this can propagate through one or more layers of stacked devices, some
of which have forwarding tables which which use the VLAN ID and/or
protocol as one of the primaries keys.

Changing the VLAN id and protocol is a huge operation with many far
reaching implications.

      reply	other threads:[~2018-07-08  1:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-10 23:19 [PATCH net-next] vlan: implement vlan id and protocol changes Chas Williams
2018-06-11  0:15 ` kbuild test robot
2018-06-11 23:44 ` [PATCH v2 " Chas Williams
2018-06-25 10:30 ` [PATCH v3,net-next] " Chas Williams
2018-06-25 20:45   ` David Ahern
2018-06-26 10:32     ` Ido Schimmel
     [not found]       ` <CAG2-GkmUJCc2bvOpaXsnUsEeJCLjWeYrs4Xe2kF_9M48FMRTzA@mail.gmail.com>
2018-06-26 15:29         ` Ido Schimmel
     [not found]     ` <CAG2-Gkm0u3Od64nAMpUzq+=M+cj3VS0J1VQ8L5BChbo7vig+kA@mail.gmail.com>
2018-06-26 15:57       ` Ido Schimmel
2018-07-02 22:35 ` [PATCH v4,net-next] " Chas Williams
2018-07-07 11:11   ` David Miller
2018-07-07 13:14     ` Ido Schimmel
2018-07-08  1:23       ` David Ahern
2018-07-08  1:47         ` David Miller [this message]

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=20180708.104744.768358766310806101.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=3chas3@gmail.com \
    --cc=dsahern@gmail.com \
    --cc=idosch@idosch.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).