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 <piotr.skam...@intel.com> 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&#322owackiego 173 | 80-298 Gda&#324sk | S&#261d Rejonowy Gda&#324sk
> P&#243&#322noc | VII Wydzia&#322 Gospodarczy Krajowego Rejestru S&#261dowego
> - KRS 101882 | NIP 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie nadawcy
> oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dmitry Borodaenko

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to