Thread (5 messages) 5 messages, 3 authors, 2016-02-25

Re: [PATCH][net-next][v2] bridge: allow the maximum mtu to 64k

flat view

From: David Miller <davem@davemloft.net>
Date: 2016-02-25 19:28:45

From: Li RongQing <redacted>
Date: Thu, 25 Feb 2016 09:50:41 +0800
On Thu, Feb 25, 2016 at 5:44 AM, Stephen Hemminger
[off-list ref] wrote:
quoted
quoted
This is especially annoying for the virtualization case because the
KVM's tap driver will by default adopt the bridge's MTU on startup
making it impossible (without the workaround) to use a large MTU on the
guest VMs.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064
This use case looks like KVM misusing bridge MTU. I.e it should set TAP
MTU to what it wants then enslave it, not vice versa.
1. a use should be able to configure an empty bridge MTU to a higher
mtu than 1500

2. if first configure the tap MTU a higher value, other port is lower
value, the pmtu
will be used, it maybe lower performance.
the configuration process is written into libvirt, located in
virnetdevtap.c, of cause it can
be improved to fix this issue.
https://www.redhat.com/archives/libvir-list/2008-December/msg00083.html
You are saying that it is possible to achieve the behavior the user wants
with the mechanisms provided, which means this patch isn't necessary.

And if I added the patch it would be of limited value, since proper software
would have to cope with the behavior of older kernels anyways.

I'm not applying this, sorry.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help