netdev - Re: [PATCH net 0/2] vxlan: Set a large MTU on ovs-created vxlan devices

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 07 Jan 2016 16:47:46 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	david@...ve.works
Cc:	netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [PATCH net 0/2] vxlan: Set a large MTU on ovs-created vxlan
 devices

From: David Wragg <david@...ve.works>
Date: Wed, 06 Jan 2016 23:25:56 +0000

> Considering non-openvswitch scenarios, when using vxlan netdevs
> directly, a vxlan netdev locked to an underlying device supporting jumbo
> frames can use a larger MTU.  It's only vxlan netdevs without an
> underlying device that have the limit of 1500 imposed.  But why
> shouldn't there be the same flexibility to select an MTU for best
> performance in both cases?  Aren't the fragmentation concerns the same?

When there is an underlying device, there are no fragmentation concerns
and PMTU will function properly because the MTU will be set accurately.

> True.  But in what sense is 1500 accurate?  Uses/users of the kernel
> openvswitch code have always had to get this right, making sure that
> the MTU set on a vxlan overlay network conforms to the underlying
> network paths involved.

"right" is a subjective thing.

Here, once again, the poorly thought out amount of flexibility
openvswitch provides is going to have a serious negative consequence
for our implementation.

I'm really tired of seeing this happen over and over again.
Openvswitch's growth and the expansion of it's feature set was
extremely poorly managed.