Hi, With the path_mtu issue - our default was to set path_mtu to zero, and do no calculation against the physical segment MTU and the overhead for the tunneling protocol that was selected for a tenant network. Which means the network would break.
I am working on patches to change our behavior to set the MTU to 1500 by default[1], so that at least our out of the box experience is more sensible. This brings me to the csum feature of recent linux kernel versions and related network components. Patches: https://review.openstack.org/#/c/220744/ https://review.openstack.org/#/c/261409/ Bugs/RFEs: https://bugs.launchpad.net/neutron/+bug/1515069 https://bugs.launchpad.net/neutron/+bug/1492111 Basically, we see that enabling the csum feature creates the conditions where 10gig link were able to be fully utilized[2] in one instance[3]. My thinking is - yes I too would like to fully utilize the links that I paid good money for. Someone with more knowledge can correct me , but is there any reason not to enable this feature? If your hardware supports it, we should utilize it. If your hardware doesn't support it, then we shouldn't. tl;dr - why do we keep merging features that create more knobs that deployers and deployment tools need to keep turning? The fact that we merge features that are disabled by default means that they are not as thoroughly tested as features that are enabled by default. Neutron should have a lot of things enabled by default that improve performance (l2pop? path_mtu? dvr?), and by itself, try and enable these features. If for some reason the hardware doesn't support it, log that it wasn't successful and then disable. OK - that's it for me. Thanks for reading. I'll put on my asbestos undies now. [1]: https://review.openstack.org/#/c/276411/ [2]: http://openvswitch.org/pipermail/dev/2015-August/059335.html [3]: Yes, it's only one data point.... -- Sean M. Collins __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
