Bug 1750280

Let's look at how kernel handles MTU assignment when there are master
or parent relationships:

 - the MTU of a VLAN is initially set to same value as master, and it
   is not updated when the master changes (except to avoid that the
   VLAN MTU doesn't exceed master's).

 - for bonds, the slaves' MTU is automatically set to match the bond
   MTU upon enslavement and it is also updated when the bond MTU
   changes. It is also reset to the previous value when the slave is
   released. The slaves' MTU can be explicitly set by user to a
   different value, but this is going to break things for modes other
   than active-backup.

 - teams are handled in the same way as bonds: the kernel propagates
   the MTU from master to slaves.

 - for bridges, unless overridden by user, the bridge MTU is
   automatically updated when a port is added/removed to match the
   minimum of slaves' MTU. So ports can have different MTUs and if the
   destination port of a frame has a MTU lower than the frame size the
   frame gets dropped.

Now the NM side:

 - NM already keeps the MTU of VLANs aligned to master (unless
   explicitly overridden by user).

 - for bonds and teams no action seems necessary because kernel
   already takes care of propagating the MTU to slaves

 - currently it doesn't propagate the MTU to bridge slaves.

The only part missing seems to be bridges. Maybe we should implement a
propagation mechanism to slaves, but only when the MTU is explicitly
set on the bridge connection, not when the kernel changes the bridge
MTU after adding/removing a port because it seems wrong to propagate
one of the slaves' MTU to others.

There are also open questions about the implementation... if a vlan is
enslaved to a bridge, should it get the MTU from the parent or from
the bridge?

Anyway, I consider this a nice-to-have but not strictly a necessary
feature since without any configuration the bridge will get the right
MTU from slaves. If users care about setting a different value, they
can also set the slaves MTU to the needed value that I guess can be
also a different value than master's in particular scenarios.

What do others think?

(In reply to Beniamino Galvani from comment #2)
> The only part missing seems to be bridges. Maybe we should implement a
> propagation mechanism to slaves, but only when the MTU is explicitly
> set on the bridge connection, not when the kernel changes the bridge
> MTU after adding/removing a port because it seems wrong to propagate
> one of the slaves' MTU to others.

Everything sounds right to me so far.
We have encountered bridges in a few incidents now, and it seems their MTU
affects only the management interface but not the forwarding. Therefore,
changing a bridge MTU should not have side effects.

Ales, based on this info, do you have an example of something that you
still think is relevant to this request? If not, I guess we can close it.

(In reply to Edward Haas from comment #3)
> (In reply to Beniamino Galvani from comment #2)
> > The only part missing seems to be bridges. Maybe we should implement a
> > propagation mechanism to slaves, but only when the MTU is explicitly
> > set on the bridge connection, not when the kernel changes the bridge
> > MTU after adding/removing a port because it seems wrong to propagate
> > one of the slaves' MTU to others.
> 
> Everything sounds right to me so far.
> We have encountered bridges in a few incidents now, and it seems their MTU
> affects only the management interface but not the forwarding. Therefore,
> changing a bridge MTU should not have side effects.
> 
> Ales, based on this info, do you have an example of something that you
> still think is relevant to this request? If not, I guess we can close it.

Seems reasonable enough. Closing as not a bug.