[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180708.104744.768358766310806101.davem@davemloft.net>
Date: Sun, 08 Jul 2018 10:47:44 +0900 (KST)
From: David Miller <davem@...emloft.net>
To: dsahern@...il.com
Cc: idosch@...sch.org, 3chas3@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v4,net-next] vlan: implement vlan id and protocol
changes
From: David Ahern <dsahern@...il.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.
Powered by blists - more mailing lists