On Thu, Mar 29, 2018 at 9:02 PM, Toshiaki Makita <makita.toshi...@lab.ntt.co.jp> wrote: > On 2018/03/30 1:49, Roopa Prabhu wrote: >> On Thu, Mar 22, 2018 at 9:53 PM, Roopa Prabhu <ro...@cumulusnetworks.com> >> wrote: >>> On Thu, Mar 22, 2018 at 8:34 AM, Chas Williams <3ch...@gmail.com> wrote: >>>> 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 <3ch...@gmail.com> >>>> --- >>> >>> Acked-by: Roopa Prabhu <ro...@cumulusnetworks.com> >>> >>> 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. 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. >> >> The other equivalent fix i was thinking about is to keep the default >> behavior as is, and allow a max mtu to be >> configured on the bridge. This will allow a sys admin to fix the >> current mtu limitations if >> deployments require it. >> >> we will submit an incremental patch to re-work this patch to restore >> default behavior. > > +1 > > This makes sense to me. > > -- > Toshiaki Makita >
