Sorry... I guess our discussion here is in line with the "good practices" 
discussion. For a long time I see a lot of mentions on having a front-end and a 
back-end network when dealing with distributed file systems like Gluster and 
Ceph. What I would like to here from those who already implemented oVirt on the 
field is "what is the real life" approach for good performance as large 
file/memory transfers will strongly benefit from having a big MTU. However, big 
MTU must be driven correctly otherwise you may end-up having the problem we are 


From: Moacir Ferreira <>
Sent: Tuesday, August 8, 2017 3:16 PM
To: Fabrice Bacchella
Subject: Re: [ovirt-users] Users Digest, Vol 71, Issue 37

Exactly Fabrice! In this case the router will fragment the "bigger" MTU to fit 
the "smaller" MTU but only when the DF is not set. However, fragmentation on 
routers are made by the control plane, meaning you will overload the router CPU 
doing too much fragmentation. On a good NIC the announced MTU to the IP stack 
is very big (like 64Kb) because the off-load engine will fragment this very 
large MTU and send it. But on this kind of NIC the fragmentation is done by 
dedicated AISCs that does not require any CPU intervention to do it. Just give 
it a try... Assemble a lab using Linux and you will see what I am trying to 


From: Fabrice Bacchella <>
Sent: Tuesday, August 8, 2017 2:50 PM
To: Moacir Ferreira
Subject: Re: [ovirt-users] Users Digest, Vol 71, Issue 37

Le 8 août 2017 à 14:53, Moacir Ferreira 
<<>> a écrit :

But if you receive a 9000 MTU frame on an "input" interface that results 
sending it out on an interface of a 1500 MTU, then if you set DF bit the frame 
will just be dropped by the router.

The frame will be dropped and the router will send an ICMP message "packet to 
big" to the sender, it's network stack will received that, learn that the PMTU 
is lower and try with smaller fragment, see

Users mailing list

Reply via email to