Open Stack

On 18 April 2016 at 04:33, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Akihiro Motoki <amotoki at gmail.com> wrote:
>
> 2016-04-18 15:58 GMT+09:00 Ihar Hrachyshka <ihrachys at redhat.com>:
>>
>>> Sławek Kapłoński <slawek at kaplonski.pl> wrote:
>>>
>>> Hello,
>>>>
>>>> What MTU have You got configured on VMs? I had issue with performance on
>>>> vxlan network with standard MTU (1500) but when I configured Jumbo
>>>> frames on vms and on hosts then it was much better.
>>>>
>>>
>>>
>>> Right. Note that custom MTU works out of the box only starting from
>>> Mitaka.
>>
>>
It's been in from at least Kilo (give or take a some bugfixes, it seems,
all of which deserve backporting).

You can find details on how to configure Neutron for Jumbo frames in the
>>> official docs:
>>>
>>> http://docs.openstack.org/mitaka/networking-guide/adv-config-mtu.html
>>>
>>
>> If you want to advertise MTU using DHCP in releases before Mitaka,
>> you can prepare your custom dnsmasq config file like below and
>> set it to dhcp-agent dnsmasq_config_file config option.
>> You also need to set network_device_mtu config parameters appropriately.
>>
>> sample dnsmasq config file:
>> --
>> dhcp-option-force=26,8950
>> --
>> dhcp option 26 specifies MTU.
>>
>
> Several notes:
>
> - In Liberty, above can be achieved by setting advertise_mtu in
> neutron.conf on nodes hosting DHCP agents.
> - You should set [ml2] segment_mtu on controller nodes to MTU value for
> underlying physical networks. After that, DHCP agents will advertise
> correct MTU for all new networks created after the configuration applied.
> - It won’t work in OVS hybrid setup, where intermediate devices (qbr) will
> still have mtu = 1500, that will result in Jumbo frames dropped. We have
> backports to fix it in Liberty at: https://review.openstack.org/305782
> and https://review.openstack.org/#/c/285710/
>

Indeed, you can actively request the MTU per virtual network as you create
them, subject to segment_mtu and path_mtu indicating they're achievable.

In this instance, configure your switches with a 9000 MTU and set
segment_mtu = path_mtu = 9000.  The virtual network MTU will then default
to 8950 for a VXLAN network (the biggest possible packet inside VXLAN in
that circumstance) and you can choose to set it to anything else below that
number as you net-create.  The MTU should be correctly advertised by DHCP
when set.

I hope you don't find you have to do what Akihiro suggests.  That was good
advice about three releases back but nowadays it actually breaks the code
that's there to deal with MTUs properly.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160419/b5e31647/attachment.html>