Open Stack

I agree with the mtu setting because there isn't much of a downside to
enabling it. However, the others do have reasons to be disabled.

csum - requires runtime detection of support for a feature and then auto
degradation for systems that don't support it. People were against those so
we have the whole sanity check framework instead. I wouldn't be opposed to
revisiting that decision, but it's definitely a blocker right now.

dvr - doesn't work in non-VM cases (e.g. floating IP pointing to allowed
address pair or bare metal host) and consumes more public IPs than legacy
or HA.

l2pop - this one is weird because it's an ML2 driver. It makes no sense to
have it always enabled because an operator could be using an l2pop
incompatible backend. We also don't have a notion of a driver enabled by
default so if we did want to do it, it would take a bunch of changes to
ML2.

Whenever we have a knob, it usually stems from the fact that we don't use
runtime feature detection or the feature has a tradeoff that doesn't make
its use obvious in all cases.
On Feb 8, 2016 07:50, "Sean M. Collins" <sean at coreitpro.com> wrote:

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160209/cd318caf/attachment.html>