[PATCH] net:bridge:always disable auto-tuning when the user specified MTU

[PATCH] net:bridge:always disable auto-tuning when the user specified MTU

[Huang Rui]

For example.
My purpose is to create a bridge br0 and join eth0 into br0.
if we use this following way, the auto-tuning flag will not be disabled.

If eth0's mtu is 1200
step 1.brctl addbr br0
step 2.brctl addif br0 eth0
step 3.ifconfig br0 mtu 1200
step 4.ifconfig eth0 mtu 1500

Result:
br0's MTU: 1500, eth0's MTU: 1500

Expected:
br0's MTU: 1200, eth0's MTU: 1500

I have specified br0's MTU,  but auto-min policy works. So the MTU is
not the result what we expected.
As expected, if i have specified bridge's MTU, it will set the flag:
BROPT_MTU_SET_BY_USER in net_bridge_opts disabled and auto-min/max
policy will not work.But in this case, because the dev_set_mtu return
early, the BROPT_MTU_SET_BY_USER flag will not be disabled and
auto-min/max policy will still work.

Signed-off-by: Huang Rui <huangruiPPP@gmail.com>
---
 net/core/dev.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 2b67f2aa59dd..ba410d76bb49 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7670,8 +7670,12 @@ int dev_set_mtu_ext(struct net_device *dev, int new_mtu,
 {
 	int err, orig_mtu;
 
-	if (new_mtu == dev->mtu)
-		return 0;
+	if (new_mtu == dev->mtu) {
+		if (dev->priv_flags & IFF_EBRIDGE)
+			return __dev_set_mtu(dev, new_mtu);
+		else
+			return 0;
+	}
 
 	/* MTU must be positive, and in range */
 	if (new_mtu < 0 || new_mtu < dev->min_mtu) {
-- 
2.11.0

Re: [PATCH] net:bridge:always disable auto-tuning when the user specified MTU

[Stephen Hemminger]

On Wed, 10 Apr 2019 02:32:08 +0000
Huang Rui <huangruippp@gmail.com> wrote:

> For example.
> My purpose is to create a bridge br0 and join eth0 into br0.
> if we use this following way, the auto-tuning flag will not be disabled.
> 
> If eth0's mtu is 1200
> step 1.brctl addbr br0
> step 2.brctl addif br0 eth0
> step 3.ifconfig br0 mtu 1200
> step 4.ifconfig eth0 mtu 1500
> 
> Result:
> br0's MTU: 1500, eth0's MTU: 1500
> 
> Expected:
> br0's MTU: 1200, eth0's MTU: 1500
> 
> I have specified br0's MTU,  but auto-min policy works. So the MTU is
> not the result what we expected.
> As expected, if i have specified bridge's MTU, it will set the flag:
> BROPT_MTU_SET_BY_USER in net_bridge_opts disabled and auto-min/max
> policy will not work.But in this case, because the dev_set_mtu return
> early, the BROPT_MTU_SET_BY_USER flag will not be disabled and
> auto-min/max policy will still work.
> 
> Signed-off-by: Huang Rui <huangruiPPP@gmail.com>

A bridge like this going to drop frames.
A frame received with MTU of 1200 will get dropped.
The proper way to do this is to change MTU of both interfaces to match.

Re: [PATCH] net:bridge:always disable auto-tuning when the user specified MTU

[Petr Machata]

Stephen Hemminger <stephen@networkplumber.org> writes:

> On Wed, 10 Apr 2019 02:32:08 +0000
> Huang Rui <huangruippp@gmail.com> wrote:
>
>> For example.
>> My purpose is to create a bridge br0 and join eth0 into br0.
>> if we use this following way, the auto-tuning flag will not be disabled.
>>
>> If eth0's mtu is 1200
>> step 1.brctl addbr br0
>> step 2.brctl addif br0 eth0
>> step 3.ifconfig br0 mtu 1200
>> step 4.ifconfig eth0 mtu 1500
>>
>> Result:
>> br0's MTU: 1500, eth0's MTU: 1500
>>
>> Expected:
>> br0's MTU: 1200, eth0's MTU: 1500
>>
>> I have specified br0's MTU,  but auto-min policy works. So the MTU is
>> not the result what we expected.
>> As expected, if i have specified bridge's MTU, it will set the flag:
>> BROPT_MTU_SET_BY_USER in net_bridge_opts disabled and auto-min/max
>> policy will not work.But in this case, because the dev_set_mtu return
>> early, the BROPT_MTU_SET_BY_USER flag will not be disabled and
>> auto-min/max policy will still work.
>>
>> Signed-off-by: Huang Rui <huangruiPPP@gmail.com>
>
> A bridge like this going to drop frames.
> A frame received with MTU of 1200 will get dropped.

That's true even if above you set br0's MTU to 1201, but then the
auto-tuning is disabled as expected. The problem is that setting MTU to
1200 is perceived as a non-change, whereas it should instead be
perceived as a signal that the user takes over the MTU management.

> The proper way to do this is to change MTU of both interfaces to match.

Re: [PATCH] net:bridge:always disable auto-tuning when the user specified MTU

[Nikolay Aleksandrov]

On 10/04/2019 13:34, Petr Machata wrote:
> 
> Stephen Hemminger <stephen@networkplumber.org> writes:
> 
>> On Wed, 10 Apr 2019 02:32:08 +0000
>> Huang Rui <huangruippp@gmail.com> wrote:
>>
>>> For example.
>>> My purpose is to create a bridge br0 and join eth0 into br0.
>>> if we use this following way, the auto-tuning flag will not be disabled.
>>>
>>> If eth0's mtu is 1200
>>> step 1.brctl addbr br0
>>> step 2.brctl addif br0 eth0
>>> step 3.ifconfig br0 mtu 1200
>>> step 4.ifconfig eth0 mtu 1500
>>>
>>> Result:
>>> br0's MTU: 1500, eth0's MTU: 1500
>>>
>>> Expected:
>>> br0's MTU: 1200, eth0's MTU: 1500
>>>
>>> I have specified br0's MTU,  but auto-min policy works. So the MTU is
>>> not the result what we expected.
>>> As expected, if i have specified bridge's MTU, it will set the flag:
>>> BROPT_MTU_SET_BY_USER in net_bridge_opts disabled and auto-min/max
>>> policy will not work.But in this case, because the dev_set_mtu return
>>> early, the BROPT_MTU_SET_BY_USER flag will not be disabled and
>>> auto-min/max policy will still work.
>>>
>>> Signed-off-by: Huang Rui <huangruiPPP@gmail.com>
>>
>> A bridge like this going to drop frames.
>> A frame received with MTU of 1200 will get dropped.
> 
> That's true even if above you set br0's MTU to 1201, but then the
> auto-tuning is disabled as expected. The problem is that setting MTU to
> 1200 is perceived as a non-change, whereas it should instead be
> perceived as a signal that the user takes over the MTU management.
> 
>> The proper way to do this is to change MTU of both interfaces to match.

The only problem is a lot of the network configuration software these days
sets the MTU by default and that would lead to disabling auto-tune by default.
And since you haven't received a notification it means nothing has changed,
but in this case state has changed for the bridge quietly. It could break setups
which rely on the auto-tune and it would do it quietly which won't be easy to debug.

Also as I said in my previously, I really don't like adding bridge-specific
code in there. Another more ambitious approach would be to maybe always pass the
value to the drivers and let them deal with it, that would require going through all
ndo_change_mtu users and also would still not solve the problem of not sending
a notification when there has been a state change (the bridge no longer auto-tunes).
Thus the bridge will probably have to emit *some* notification by itself.

Perhaps this should've been a bridge option from the start instead of automatic
decision but it's late for that now.

Thanks,
 Nik

Re: [PATCH] net:bridge:always disable auto-tuning when the user specified MTU

[黄睿]

Whether use the current method to configure bridge's MTU or
add a notification in bridge's internal code and send a notification
when modify the bridge's MTU, we all need to add an additional
judgement in dev_set_mtu_ext's first if statement for bridge to
let the process not return early.

By the way, whether it is the expected result or the current result,
the MTU of the bridge will not be larger than the interface in the bridge.
Which scene will cause frame drop.

Nikolay Aleksandrov <nikolay@cumulusnetworks.com> 于2019年4月10日周三 下午7:05写道：
>
> On 10/04/2019 13:34, Petr Machata wrote:
> >
> > Stephen Hemminger <stephen@networkplumber.org> writes:
> >
> >> On Wed, 10 Apr 2019 02:32:08 +0000
> >> Huang Rui <huangruippp@gmail.com> wrote:
> >>
> >>> For example.
> >>> My purpose is to create a bridge br0 and join eth0 into br0.
> >>> if we use this following way, the auto-tuning flag will not be disabled.
> >>>
> >>> If eth0's mtu is 1200
> >>> step 1.brctl addbr br0
> >>> step 2.brctl addif br0 eth0
> >>> step 3.ifconfig br0 mtu 1200
> >>> step 4.ifconfig eth0 mtu 1500
> >>>
> >>> Result:
> >>> br0's MTU: 1500, eth0's MTU: 1500
> >>>
> >>> Expected:
> >>> br0's MTU: 1200, eth0's MTU: 1500
> >>>
> >>> I have specified br0's MTU,  but auto-min policy works. So the MTU is
> >>> not the result what we expected.
> >>> As expected, if i have specified bridge's MTU, it will set the flag:
> >>> BROPT_MTU_SET_BY_USER in net_bridge_opts disabled and auto-min/max
> >>> policy will not work.But in this case, because the dev_set_mtu return
> >>> early, the BROPT_MTU_SET_BY_USER flag will not be disabled and
> >>> auto-min/max policy will still work.
> >>>
> >>> Signed-off-by: Huang Rui <huangruiPPP@gmail.com>
> >>
> >> A bridge like this going to drop frames.
> >> A frame received with MTU of 1200 will get dropped.
> >
> > That's true even if above you set br0's MTU to 1201, but then the
> > auto-tuning is disabled as expected. The problem is that setting MTU to
> > 1200 is perceived as a non-change, whereas it should instead be
> > perceived as a signal that the user takes over the MTU management.
> >
> >> The proper way to do this is to change MTU of both interfaces to match.
>
> The only problem is a lot of the network configuration software these days
> sets the MTU by default and that would lead to disabling auto-tune by default.
> And since you haven't received a notification it means nothing has changed,
> but in this case state has changed for the bridge quietly. It could break setups
> which rely on the auto-tune and it would do it quietly which won't be easy to debug.
>
> Also as I said in my previously, I really don't like adding bridge-specific
> code in there. Another more ambitious approach would be to maybe always pass the
> value to the drivers and let them deal with it, that would require going through all
> ndo_change_mtu users and also would still not solve the problem of not sending
> a notification when there has been a state change (the bridge no longer auto-tunes).
> Thus the bridge will probably have to emit *some* notification by itself.
>
> Perhaps this should've been a bridge option from the start instead of automatic
> decision but it's late for that now.
>
> Thanks,
>  Nik