[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53576A6F.2020207@6wind.com>
Date: Wed, 23 Apr 2014 09:23:27 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: chenweilong <chenweilong@...wei.com>,
Eric Dumazet <eric.dumazet@...il.com>
CC: kaber@...sh.net, davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [patch net-next] vlan: Don't allow vlan devices to change network
namespaces.
Le 23/04/2014 04:40, chenweilong a écrit :
> On 2014/4/22 22:26, Eric Dumazet wrote:
>> On Tue, 2014-04-22 at 20:43 +0800, Chen Weilong wrote:
>>> From: Weilong Chen <chenweilong@...wei.com>
>>>
>>> Like bonding, vlan as netdevice doesn't cross netns boundaries.
>>>
>>> Vlan port and vlan itself live in same netns.
>>
>> Please explain why you believe it should be like that.
>>
>> bonding and vlan have quite different purpose, so your changelog is
>> quite obscure.
>>
>> We had a discussion like this one with macvlan, and prior patch was
>> rejected.
>>
>>
>>
>>
> This idea comes from the different result of two changing namespace orders.
> Test on eth1 and its vlan eth1.5, move them form default ns to a new ns called net0.
> 1.move eth1 first,and then eth1.5;
> 2.move eth1.5 first, and then eth1;
> As a network manager, I will be happy they both work, I don't care about the orders.
> But, 1) doesn't work, if eth1 was moved to other ns, all related vlans were unregisted.
> you need to create a new eth1.5 in net0.
> And, 2) is not safe, if someone forgets to move eth1, eth1.5 will not work, making
> things complex.
We have to fix this case, because it is a valid use case to have eth1.5 in net0
and eth1 in another ns.
>
> So what's the better order ?
> I prefer 1), when a vlan dev is setup, it has a namespace, and belongs to it,
> When somebody moves it, it should say 'hey boy, don't move me,I like here :0'
>
> Thanks,
> Weilong
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists