5:24 p.m.
--_000_DB6P190MB0280AE2969AE42A441462D47C88A0DB6P190MB0280EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sorry... I guess our discussion here is in line with the "good practices" d=
iscussion. For a long time I see a lot of mentions on having a front-end an=
d a back-end network when dealing with distributed file systems like Gluste=
r and Ceph. What I would like to here from those who already implemented oV=
irt on the field is "what is the real life" approach for good performance a=
s 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 t=
he problem we are discussing.
Moacir
________________________________
From: Moacir Ferreira <moacirferreira(a)hotmail.com>
Sent: Tuesday, August 8, 2017 3:16 PM
To: Fabrice Bacchella
Cc: users(a)ovirt.org
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, fragmentati=
on 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 frag=
ment this very large MTU and send it. But on this kind of NIC the fragmenta=
tion 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 explain.
Moacir
________________________________
From: Fabrice Bacchella <fabrice.bacchella(a)orange.fr>
Sent: Tuesday, August 8, 2017 2:50 PM
To: Moacir Ferreira
Cc: users(a)ovirt.org
Subject: Re: [ovirt-users] Users Digest, Vol 71, Issue 37
Le 8 ao=FBt 2017 =E0 14:53, Moacir Ferreira <moacirferreira(a)hotmail.com<mai=
lto:moacirferreira@hotmail.com>> a =E9crit :
But if you receive a 9000 MTU frame on an "input" interface that results se=
nding it out on an interface of a 1500 MTU, then if you set DF bit the fram=
e 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 th=
e PMTU is lower and try with smaller fragment, see https://en.wikipedia.org=
/wiki/Path_MTU_Discovery.
--_000_DB6P190MB0280AE2969AE42A441462D47C88A0DB6P190MB0280EURP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P
{margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper"
style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p>Sorry... I guess our discussion here is in line with the "good prac=
tices" 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 system=
s like Gluster and Ceph. What I would like
to here from those who already implemented oVirt on the field is "wha=
t is the real life" approach for good performance as large file/memory=
transfers will strongly benefit from having a big MTU. However, big MTU mu=
st be driven correctly otherwise you may end-up
having the problem we are discussing.<br>
</p>
<br>
Moacir<br>
<br>
<div style=3D"color: rgb(49, 55, 57);">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font
style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b>
Moacir Ferreira <=
;moacirferreira(a)hotmail.com&gt;<br>
<b>Sent:</b> Tuesday, August 8, 2017 3:16 PM<br>
<b>To:</b> Fabrice Bacchella<br>
<b>Cc:</b> users(a)ovirt.org<br>
<b>Subject:</b> Re: [ovirt-users] Users Digest, Vol 71, Issue 37</font>
<div> </div>
</div>
<div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr"
style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Exactly Fabrice! In this case the router will fragment the
"bigger&=
quot; MTU to fit the "smaller" MTU but only when the DF is not se=
t. 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) be=
cause the off-load engine will fragment this very large MTU and send it. Bu=
t on this kind of NIC the fragmentation is done by dedicated AISCs that doe=
s not require any CPU intervention
to do it. Just give it a try... Assemble a lab using Linux and you will se=
e what I am trying to explain.<br>
</p>
<br>
Moacir<br>
<br>
<div style=3D"color:rgb(49,55,57)">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font
style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b>
Fabrice Bacchella &=
lt;fabrice.bacchella(a)orange.fr&gt;<br>
<b>Sent:</b> Tuesday, August 8, 2017 2:50 PM<br>
<b>To:</b> Moacir Ferreira<br>
<b>Cc:</b> users(a)ovirt.org<br>
<b>Subject:</b> Re: [ovirt-users] Users Digest, Vol 71, Issue 37</font>
<div> </div>
</div>
<div><br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">Le 8 ao=FBt 2017 =E0 14:53, Moacir Ferreira <<a
href=3D"=
mailto:moacirferreira@hotmail.com"
class=3D"">moacirferreira(a)hotmail.com</a=
> a =E9crit :</div>
<br
class=3D"Apple-interchange-newline">
<div class=3D"">
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" class=3D""
style=3D"font-style=
:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-alig=
n:start; text-indent:0px; text-transform:none; white-space:normal; widows:a=
uto; word-spacing:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-s=
erif">
<div class=3D"" style=3D"margin-top:0px; margin-bottom:0px">But
if you rece=
ive 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 fram=
e will just be dropped by the router.</div>
</div>
</div>
</blockquote>
<br class=3D"">
</div>
The frame will be dropped and the router will send an ICMP message "pa=
cket to big" to the sender, it's network stack will received that, lea=
rn that the PMTU is lower and try with smaller fragment, see <a href=
=3D"https://en.wikipedia.org/wiki/Path_MTU_Discovery"
class=3D"">https://en=
.wikipedia.org/wiki/Path_MTU_Discovery</a>.
<div class=3D""><br class=3D"">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
--_000_DB6P190MB0280AE2969AE42A441462D47C88A0DB6P190MB0280EURP_--