--_000_DB6P190MB0280AA323133DF5B38214555C88A0DB6P190MB0280EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is by far more complex. A good NIC will have an offload engine (LSO - = Large Segment Offload) and, if so, the NIC driver will report a MTU of 64K = to the IP stack. The IP stack will then send data to the NIC as if the MTU = were 64K and the NIC will fragment it to the size of the "declared" MTU on = the interface so PMTUD will not be efficient in such scenario. If all this = takes place in the server, then you get no problem. But if a standard route= r is configured to support 9K jumbo frame in one interface (i.e.: LAN conne= ction) and 1500 in another (i.e.: WAN connection) then the router will be r= esponsible for the fragmentation. However, most of the routers out there ar= e not able to deal with this in high traffic demands. Splitting the very intensive east/west traffic like disk copies, VM moves, = etc. from the "service" traffic will not only prevent contention but also f= ix this problem with MTU. Moacir ________________________________ From: Yaniv Kaul <ykaul@redhat.com> Sent: Tuesday, August 8, 2017 7:35 AM To: Moacir Ferreira Cc: users@ovirt.org Subject: Re: [ovirt-users] Users Digest, Vol 71, Issue 37 On Tue, Aug 8, 2017 at 12:42 AM, Moacir Ferreira <moacirferreira@hotmail.co= m<mailto:moacirferreira@hotmail.com>> wrote: Fabrice, If you choose to have jumbo frames all over, then when the traffic goes out= side of your "jumbo frames" enabled network it will be necessary to be frag= mented back again to the destination MTU. Most of the datacenters will prov= ide services to the outside world where the MTU is 1500 bytes. In this case= , you will slow down your performance because your router will be doing the= fragmentation. So I would always use jumbo frames in the datacenter for ea= st/west traffic and standard (1500 bytes) for north/south traffic. I doubt this would happen with modern TCP/IP stacks, for TCP connections. I= t'll adjust to the path most likely, using PMTUD. Of course, this does not = always work (depends on HW en-route). UDP packets might fail miserably too (dropped), depending on the HW en-rout= e, but UDP traffic (and specifically large packets) are not that common the= se days. Nevertheless, I don't see a huge advantage in enabling this for north-south= traffic, TBH, and the mysterious, random traffic drop issues it may cause = is not worth it. Y. Moacir ---------------------------------------------------------------------- Message: 1 Date: Mon, 7 Aug 2017 21:50:36 +0200 From: Fabrice Bacchella <fabrice.bacchella@orange.fr<mailto:fabrice.bacchel= la@orange.fr>> To: FERNANDO FREDIANI <fernando.frediani@upx.com<mailto:fernando.frediani@u= px.com>> Cc: users@ovirt.org<mailto:users@ovirt.org> Subject: Re: [ovirt-users] Good practices Message-ID: <4365E3F7-4C77-4FF5-8401-1CDA2F0029EE@orange.fr<mailto:4365E3F7= -4C77-4FF5-8401-1CDA2F0029EE@orange.fr>> Content-Type: text/plain; charset=3D"windows-1252"
Moacir: Yes! This is another reason to have separate networks for north/= south and east/west. In that way I can use the standard MTU on the 10Gb NIC= s and jumbo frames on the file/move 40Gb NICs.
Why not Jumbo frame every where ?