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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20160225.142843.1047807549399216518.davem@davemloft.net>
Date:	Thu, 25 Feb 2016 14:28:43 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	roy.qing.li@...il.com
Cc:	stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: [PATCH][net-next][v2] bridge: allow the maximum mtu to 64k

From: Li RongQing <roy.qing.li@...il.com>
Date: Thu, 25 Feb 2016 09:50:41 +0800

> On Thu, Feb 25, 2016 at 5:44 AM, Stephen Hemminger
> <stephen@...workplumber.org> wrote:
>>> 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.