Hi Piotr, Thanks for writing up a detailed summary of the problem! At the moment, we have a way to set MTU using Fuel CLI [0] and a blueprint to add this functionality to Fuel Web UI [1]
[0] http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#adjust-the-network-configuration-via-cli [1] https://blueprints.launchpad.net/fuel/+spec/set-mtu-for-interfaces I'm not sure it's safe to assume that if you have a 10G NICs the rest of your network is going to support jumbo frames, do you think simply being able to set MTU explicitly (when you know for a fact that particular MTU value works) would be good enough of a solution? On Mon, Jan 12, 2015 at 1:24 PM, Skamruk, Piotr <[email protected]> wrote: > Hi. > > > > I’m testing OpenStack setup set on our hardware with Fuel 6.0 and I found > the problem with 10Gbit network interfaces configuration. > > Our setup uses Centos on deployed nodes – I didn’t look how this situation > looks from Ubuntu perspective, but looking on the fuel-library – there is > probably the same effect. > > > > With default settings, nodes deployed by fuel have 2.6.32.xxx linux kernel, > with 3.10 available and marked as “experimental”. > > Under webui for deployment, network interfaces are correctly shown as > running on 10Gbit, but… Maximal transfer rates which We could achieve were > around 2.5Gbit/s. > > > > After some investigation I found that interfaces configured by > /etc/sysconfig/network-scripts/ifcfg-* have set default MTU, no matter if > particular interface is or is not 10Gbit. I did not searched how other than > igxbe drivers works, but this particular under so old kernels in 10Gbit > configuration requires MTU set to at least 9000 (to turn on jumbo frames – > probably other drivers have similar requirement), to work properly. > > > > Manual adding (this is only simplification, this should be set more > carefully): > > for f in /etc/sysconfig/network-scripts/ifcfg-* ; do echo “MTU=9000” >>$f > ; done > > partially resolves this problem (partially, because under default 2.6.32.xxx > still We do not have better than 6Gbit/s transfers in single stream, but > situation is much better under mentioned above 3.10 kernel – We have full > 10Gbit/s). > > > > Looking into fuel-library, l23network::l3::ifconfig have ability to also > configure MTU, but this functionality looks unused in this situation. > > > > End user which buys setup with 10Gbit/s 82599 based network adapters expects > that in default configuration “all should work as expected”. From user > perspective – actual situation is faulty. > > For this moment – not only in time of deploy he must select option marked as > “experimental”, but also he must patch deployed setup, and remember to patch > in same way every one added in future physical node. > > > > So, what We can do to make end user happier? > > Could We in puppet files do something like: > > if interface_link == ‘10Gbit’ and interface_driver == ‘igxbe’: > > set_mtu(9000) > > interface_driver could be readed from link name, from > /sys/class/net/<devname>/device/driver/module > > interface_link could be readed from ethtool <devname> | grep Speed > > > > --------------------------------------------------------------------- > Intel Technology Poland sp. z o.o. > ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk > Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego > - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN. > > Ta wiadomość wraz z załącznikami jest przeznaczona dla > określonego adresata i może zawierać informacje poufne. W razie > przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy > oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub > rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). If you are not the intended > recipient, please contact the sender and delete all copies; any review or > distribution by others is strictly prohibited. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Dmitry Borodaenko __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
