* Cannot move macvlan interface on top of bonding device
@ 2014-09-17 15:56 Francesco Ruggeri
2014-09-17 16:46 ` Cong Wang
0 siblings, 1 reply; 10+ messages in thread
From: Francesco Ruggeri @ 2014-09-17 15:56 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Weilong Chen, Florian Westphal,
Francesco Ruggeri
I cannot move a macvlan interface created on top of a bonding interface
to a different namespace:
# ip netns add dummy0
# ip link add link bond0 mac0 type macvlan
# ip link set mac0 netns dummy0
RTNETLINK answers: Invalid argument
#
This used to work in older releases.
The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
to inherit its features from the lower device.
Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
lower device
by macvlan interfaces?
Thanks,
Francesco Ruggeri
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 15:56 Cannot move macvlan interface on top of bonding device Francesco Ruggeri
@ 2014-09-17 16:46 ` Cong Wang
2014-09-17 19:06 ` Florian Westphal
0 siblings, 1 reply; 10+ messages in thread
From: Cong Wang @ 2014-09-17 16:46 UTC (permalink / raw)
To: Francesco Ruggeri; +Cc: netdev, David S. Miller, Weilong Chen, Florian Westphal
On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> This used to work in older releases.
> The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
> on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
> to inherit its features from the lower device.
>
> Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
> lower device
> by macvlan interfaces?
commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
so just clear this flag. Please submit a patch.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 16:46 ` Cong Wang
@ 2014-09-17 19:06 ` Florian Westphal
2014-09-17 20:25 ` Cong Wang
2014-09-17 20:39 ` Vlad Yasevich
0 siblings, 2 replies; 10+ messages in thread
From: Florian Westphal @ 2014-09-17 19:06 UTC (permalink / raw)
To: Cong Wang
Cc: Francesco Ruggeri, netdev, David S. Miller, Weilong Chen,
Florian Westphal
Cong Wang <cwang@twopensource.com> wrote:
> On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> > This used to work in older releases.
> > The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
> > on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
> > to inherit its features from the lower device.
> >
> > Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
> > lower device
> > by macvlan interfaces?
>
> commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
> so just clear this flag. Please submit a patch.
Under which conditions would NETIF_F_NETNS_LOCAL have to be inherited?
(i.e., why is it inheritable in the first place?)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 19:06 ` Florian Westphal
@ 2014-09-17 20:25 ` Cong Wang
2014-09-17 20:39 ` Vlad Yasevich
1 sibling, 0 replies; 10+ messages in thread
From: Cong Wang @ 2014-09-17 20:25 UTC (permalink / raw)
To: Florian Westphal; +Cc: Francesco Ruggeri, netdev, David S. Miller, Weilong Chen
On Wed, Sep 17, 2014 at 12:06 PM, Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <cwang@twopensource.com> wrote:
>> On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
>> > This used to work in older releases.
>> > The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
>> > on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
>> > to inherit its features from the lower device.
>> >
>> > Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
>> > lower device
>> > by macvlan interfaces?
>>
>> commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
>> so just clear this flag. Please submit a patch.
>
> Under which conditions would NETIF_F_NETNS_LOCAL have to be inherited?
> (i.e., why is it inheritable in the first place?)
Huh? Kidding me?
Isn't the question for yourself the author of commit 797f87f83?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 19:06 ` Florian Westphal
2014-09-17 20:25 ` Cong Wang
@ 2014-09-17 20:39 ` Vlad Yasevich
2014-09-17 20:46 ` Cong Wang
2014-09-17 21:28 ` Florian Westphal
1 sibling, 2 replies; 10+ messages in thread
From: Vlad Yasevich @ 2014-09-17 20:39 UTC (permalink / raw)
To: Florian Westphal, Cong Wang
Cc: Francesco Ruggeri, netdev, David S. Miller, Weilong Chen
On 09/17/2014 03:06 PM, Florian Westphal wrote:
> Cong Wang <cwang@twopensource.com> wrote:
>> On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
>>> This used to work in older releases.
>>> The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
>>> on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
>>> to inherit its features from the lower device.
>>>
>>> Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
>>> lower device
>>> by macvlan interfaces?
>>
>> commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
>> so just clear this flag. Please submit a patch.
>
> Under which conditions would NETIF_F_NETNS_LOCAL have to be inherited?
> (i.e., why is it inheritable in the first place?)
macvlan code calls
features = netdev_increment_features(vlan->lowerdev->features,
features,
mask);
where lowerdev->features contains the NETIF_F_NETNS_LOCAL bit. That
bit is not set in features or in mask. It is also not one of the ALL_FOR_ALL
bits so it's not turned off.
As an example, here are the values from a quit test I ran:
bond features = 0x400f3888
features = 0x3b5a09 (mask is the same).
incremented features = 0x41bf389
NETIF_F_NETNS_LOCAL is still on.
May be a better solution is:
features = netdev_increment_features(vlan->lowerdev->features & MACVLAN_FEATURS,
features,
mask);
This way we start with only the feature MACVLAN is interested in.
-vlad
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 20:39 ` Vlad Yasevich
@ 2014-09-17 20:46 ` Cong Wang
2014-09-17 20:49 ` Francesco Ruggeri
2014-09-17 20:51 ` Vlad Yasevich
2014-09-17 21:28 ` Florian Westphal
1 sibling, 2 replies; 10+ messages in thread
From: Cong Wang @ 2014-09-17 20:46 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Florian Westphal, Francesco Ruggeri, netdev, David S. Miller,
Weilong Chen
On Wed, Sep 17, 2014 at 1:39 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 09/17/2014 03:06 PM, Florian Westphal wrote:
>> Cong Wang <cwang@twopensource.com> wrote:
>>> On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
>>>> This used to work in older releases.
>>>> The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
>>>> on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
>>>> to inherit its features from the lower device.
>>>>
>>>> Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
>>>> lower device
>>>> by macvlan interfaces?
>>>
>>> commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
>>> so just clear this flag. Please submit a patch.
>>
>> Under which conditions would NETIF_F_NETNS_LOCAL have to be inherited?
>> (i.e., why is it inheritable in the first place?)
>
> macvlan code calls
> features = netdev_increment_features(vlan->lowerdev->features,
> features,
> mask);
>
> where lowerdev->features contains the NETIF_F_NETNS_LOCAL bit. That
> bit is not set in features or in mask. It is also not one of the ALL_FOR_ALL
> bits so it's not turned off.
>
> As an example, here are the values from a quit test I ran:
>
> bond features = 0x400f3888
> features = 0x3b5a09 (mask is the same).
> incremented features = 0x41bf389
>
> NETIF_F_NETNS_LOCAL is still on.
I think the comment on netdev_increment_features() is clear:
* Computes a new feature set after adding a device with feature set
* @one to the master device with current feature set @all. Will not
* enable anything that is off in @mask. Returns the new feature set.
And NETIF_F_NETNS_LOCAL is on in mask.
>
> May be a better solution is:
>
> features = netdev_increment_features(vlan->lowerdev->features & MACVLAN_FEATURS,
> features,
> mask);
>
> This way we start with only the feature MACVLAN is interested in.
>
Or clear it in mask?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 20:46 ` Cong Wang
@ 2014-09-17 20:49 ` Francesco Ruggeri
2014-09-17 20:51 ` Vlad Yasevich
1 sibling, 0 replies; 10+ messages in thread
From: Francesco Ruggeri @ 2014-09-17 20:49 UTC (permalink / raw)
To: Cong Wang
Cc: Vlad Yasevich, Florian Westphal, netdev, David S. Miller,
Weilong Chen
>>
>> May be a better solution is:
>>
>> features = netdev_increment_features(vlan->lowerdev->features & MACVLAN_FEATURS,
>> features,
>> mask);
>>
>> This way we start with only the feature MACVLAN is interested in.
>>
>
> Or clear it in mask?
Do you guys see a problem with the patch I submitted (net: allow
macvlans to move to net namespace)?
Francesco
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 20:46 ` Cong Wang
2014-09-17 20:49 ` Francesco Ruggeri
@ 2014-09-17 20:51 ` Vlad Yasevich
1 sibling, 0 replies; 10+ messages in thread
From: Vlad Yasevich @ 2014-09-17 20:51 UTC (permalink / raw)
To: Cong Wang
Cc: Florian Westphal, Francesco Ruggeri, netdev, David S. Miller,
Weilong Chen
On 09/17/2014 04:46 PM, Cong Wang wrote:
> On Wed, Sep 17, 2014 at 1:39 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>> On 09/17/2014 03:06 PM, Florian Westphal wrote:
>>> Cong Wang <cwang@twopensource.com> wrote:
>>>> On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
>>>>> This used to work in older releases.
>>>>> The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
>>>>> on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
>>>>> to inherit its features from the lower device.
>>>>>
>>>>> Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
>>>>> lower device
>>>>> by macvlan interfaces?
>>>>
>>>> commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
>>>> so just clear this flag. Please submit a patch.
>>>
>>> Under which conditions would NETIF_F_NETNS_LOCAL have to be inherited?
>>> (i.e., why is it inheritable in the first place?)
>>
>> macvlan code calls
>> features = netdev_increment_features(vlan->lowerdev->features,
>> features,
>> mask);
>>
>> where lowerdev->features contains the NETIF_F_NETNS_LOCAL bit. That
>> bit is not set in features or in mask. It is also not one of the ALL_FOR_ALL
>> bits so it's not turned off.
>>
>> As an example, here are the values from a quit test I ran:
>>
>> bond features = 0x400f3888
>> features = 0x3b5a09 (mask is the same).
>> incremented features = 0x41bf389
>>
>> NETIF_F_NETNS_LOCAL is still on.
>
No, it is not. NETIF_F_NETNS_LOCAL is bit 13 and that's off. Bits
14 (GRO) and 12 (LLTX) are set.
-vlad
> I think the comment on netdev_increment_features() is clear:
>
> * Computes a new feature set after adding a device with feature set
> * @one to the master device with current feature set @all. Will not
> * enable anything that is off in @mask. Returns the new feature set.
>
> And NETIF_F_NETNS_LOCAL is on in mask.
>
>>
>> May be a better solution is:
>>
>> features = netdev_increment_features(vlan->lowerdev->features & MACVLAN_FEATURS,
>> features,
>> mask);
>>
>> This way we start with only the feature MACVLAN is interested in.
>>
>
> Or clear it in mask?
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
2014-09-17 20:39 ` Vlad Yasevich
2014-09-17 20:46 ` Cong Wang
@ 2014-09-17 21:28 ` Florian Westphal
1 sibling, 0 replies; 10+ messages in thread
From: Florian Westphal @ 2014-09-17 21:28 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Florian Westphal, Cong Wang, Francesco Ruggeri, netdev,
David S. Miller, Weilong Chen
Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 09/17/2014 03:06 PM, Florian Westphal wrote:
> > Cong Wang <cwang@twopensource.com> wrote:
> >> On Wed, Sep 17, 2014 at 8:56 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> >>> This used to work in older releases.
> >>> The problem seems to be that commit f939981492 sets NETIF_F_NETNS_LOCAL
> >>> on bonding interfaces, and commit 797f87f83 causes macvlan interfaces
> >>> to inherit its features from the lower device.
> >>>
> >>> Is there a reason why NETIF_F_NETNS_LOCAL should be inherited from the
> >>> lower device
> >>> by macvlan interfaces?
> >>
> >> commit 797f87f83 looks wrong, it should not inherit NETIF_F_NETNS_LOCAL,
> >> so just clear this flag. Please submit a patch.
> >
> > Under which conditions would NETIF_F_NETNS_LOCAL have to be inherited?
> > (i.e., why is it inheritable in the first place?)
To answer my own question: Its inherited since lowerdev->features is
passed as 'all' flag, so we would 'decrement' feature set if we'd remove
it in _increment_features().
> macvlan code calls
> features = netdev_increment_features(vlan->lowerdev->features,
> features,
> mask);
>
> where lowerdev->features contains the NETIF_F_NETNS_LOCAL bit. That
[..]
> May be a better solution is:
>
> features = netdev_increment_features(vlan->lowerdev->features & MACVLAN_FEATURS,
> features,
> mask);
>
> This way we start with only the feature MACVLAN is interested in.
Seems correct, since it will also prevent other non-macvlan features from
appearing.
Thanks Vlad.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cannot move macvlan interface on top of bonding device
@ 2014-09-18 17:36 Francesco Ruggeri
0 siblings, 0 replies; 10+ messages in thread
From: Francesco Ruggeri @ 2014-09-18 17:36 UTC (permalink / raw)
To: Florian Westphal
Cc: Vlad Yasevich, Cong Wang, netdev, David S. Miller, Weilong Chen
>
>> May be a better solution is:
>>
>> features = netdev_increment_features(vlan->lowerdev->features & MACVLAN_FEATURS,
>> features,
>> mask);
>>
>> This way we start with only the feature MACVLAN is interested in.
>
> Seems correct, since it will also prevent other non-macvlan features from
> appearing.
>
> Thanks Vlad.
I verified that this approach also solves my original problem (moving
a macvlan on top of a bonding device to a different namespace).
I do not know how to fully test it with different types of lower
devices and features though.
If anybody wants to take the lead on this it would be great. Otherwise
a more limited patch only clearing the NETIF_F_NETNS_LOCAL bit was
also submitted earlier
(http://marc.info/?l=linux-netdev&m=141097807310566&w=2).
Thanks,
Francesco
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-09-18 17:36 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-17 15:56 Cannot move macvlan interface on top of bonding device Francesco Ruggeri
2014-09-17 16:46 ` Cong Wang
2014-09-17 19:06 ` Florian Westphal
2014-09-17 20:25 ` Cong Wang
2014-09-17 20:39 ` Vlad Yasevich
2014-09-17 20:46 ` Cong Wang
2014-09-17 20:49 ` Francesco Ruggeri
2014-09-17 20:51 ` Vlad Yasevich
2014-09-17 21:28 ` Florian Westphal
-- strict thread matches above, loose matches on Subject: below --
2014-09-18 17:36 Francesco Ruggeri
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).