Open Stack

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