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