On Mon, Apr 2, 2018 at 11:08 AM, Roopa Prabhu [off-list ref] wrote:

On Fri, Mar 30, 2018 at 12:54 PM, Chas Williams [off-list ref] wrote:

quoted

On Thu, Mar 29, 2018 at 9:02 PM, Toshiaki Makita
[off-list ref] wrote:

quoted

On 2018/03/30 1:49, Roopa Prabhu wrote:

quoted

On Thu, Mar 22, 2018 at 9:53 PM, Roopa Prabhu [off-list ref] wrote:

quoted

On Thu, Mar 22, 2018 at 8:34 AM, Chas Williams [off-list ref] wrote:

quoted

If the bridge is allowing multiple VLANs, some VLANs may have
different MTUs.  Instead of choosing the minimum MTU for the
bridge interface, choose the maximum MTU of the bridge members.
With this the user only needs to set a larger MTU on the member
ports that are participating in the large MTU VLANS.

Signed-off-by: Chas Williams <3chas3@gmail.com>
---

Acked-by: Roopa Prabhu <redacted>

This or an equivalent fix is necessary: as stated above, today the
bridge mtu capped at min port mtu limits all
vlan devices on top of the vlan filtering bridge to min port mtu.

On further thought, since this patch changes default behavior, it may
upset people. ie with this patch, a vlan device
on the bridge by default will now use the  bridge max mtu and that
could cause unexpected drops in the bridge driver
if the xmit port had a lower mtu. This may surprise users.

It only changes the default behavior when you are using VLAN aware bridges.
The behavior remains the same otherwise.  I don't know if VLAN aware bridges
are that popular yet so there probably isn't any particular
expectation from those
bridges.

they are popular...in-fact they are the default bridge mode on our
network switches.
And they have been around for some time now to ignore its users.
Plus it is not right to change default mtu behavior for one mode of the bridge
and not the others (bridge mtu handling from user-space is complex enough today
due to dynamic mtu changes on port enslave/deslave).

I don't see the issue with one mode of bridge behaving differently
from another mode.
The VLAN behavior between the two bridge modes is completely different so having
a different MTU behavior doesn't seem that surprising.

You are potentially mixing different sized VLAN on a same bridge.  The only sane
choice is to pick the largest MTU for the bridge.  This lets you have
whatever MTU
is appropriate on the child VLAN interfaces of the bridge.  If you
attempt to forward
from a port with a larger MTU to a smaller MTU, you get the expected behavior.

Forcing the end user to configure all the ports to the maximum MTU of
all the VLANs
on the bridge is wrong IMHO.  You then risk attempting to forward
oversize packets
on a network that can't support that.

quoted

I don't think those drops are unexpected.  If a user has misconfigured
the bridge
we can't be expected to fix that for them.  It is the user's
responsbility to ensure
that the ports on the VLAN have a size consistent with the traffic
they expect to
pass.

By default they are not expected today. The problem is changing the bridge
to max mtu changes 'all' the vlan devices on top of the vlan aware bridge to
max mtu by default which makes drops at the bridge driver more common if the
user had mixed mtu on its ports.

That's not been my experience.  The MTU on the vlan devices is only
limited by the
bridges's MTU.  Setting the bridge MTU doesn't change the children
VLAN devices MTUs.