<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="Ubuntu">Hi David,</font></p>
<p><font face="Ubuntu">Well, frankly speaking, I don't see where is
the problem regarding the performance.</font></p>
<p><font face="Ubuntu">IMHO, the patch add an extra size of the
array i.e. from 8 bytes (2 labels) to 64 bytes (16 labels) which
is completely negligible compared to the size of a IP packet,
and of same magnitude order as a VxLan encapsulation and twice
less as an IPv6 header.</font></p>
<p><font face="Ubuntu">In addition, only the edge router as to push
the label stack. Then, subsequent router just look at the top
label. So, no more no less that a packet with only 2 labels in
the stack.</font></p>
<p><font face="Ubuntu">I think that dealing with a dynamic MPLS
STACK DEPTH i.e. dynamic memory allocation of space regarding
the number of labels are push in from of the IP packet will
certainly add more overhead and more CPU cycles rather than just
manage a fix amount of byte in an array.</font></p>
<p><font face="Ubuntu">Finally, the default value for the MPLS_LABEL_STACK
could be equal to 2 and let peoples want to deal with Segment
Routing recompile the kernel with a larger value.</font></p>
<p><font face="Ubuntu">From my side, your patch will not only
increase the label stack, it also re-arrange the MPLS structure
in order to solve the problem of corrupted third label. And,
this is the more important things.</font></p>
<p><font face="Ubuntu">In any case, let me know what I can do to
help you.<br>
</font></p>
<p><font face="Ubuntu">Regards</font></p>
<p><font face="Ubuntu">Olivier</font><br>
</p>
<br>
<div class="moz-cite-prefix">Le 16/03/2017 à 16:10, David Ahern a
écrit :<br>
</div>
<blockquote
cite="mid:dd1dc1a3-bb8a-a86b-b0af-dfe80600019c@cumulusnetworks.com"
type="cite">
<pre wrap="">I made the kernel patch to help you move along with your MPLS work.
In the kernel thread discussing the increase in number of labels Eric
Biederman mentions performance concerns about just increasing the size
of the array; he wanted a much more complicated change and I have not
gotten around to it.
On 3/16/17 3:31 AM, Olivier Dugeon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
The problem is not between the kernel and iproute2. The problem comes
when stacking more than 2 labels: the LSB byte of the third label is
replaced by 0x03 value i.e. the implicit Null Label value. See attached
thread.
Following this, David propose a new patch that we integrated and tested
successfully (See second and third attached mail).
But, after that, I got no news and never seen this patch merge into the
Linux Kernel release. So, we just ask when this patch could be merge
into the Linux Kernel.
For the second problem about PHP, it is also described in the first
attached thread. But, agree, that this issue is more tricking to solve.
Regards,
Olivier
Le 15/03/2017 à 16:59, David Ahern a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">On 3/15/17 9:57 AM, Amine Kherbouche wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> > 1) More than 2 labels in the kernel at a time, when will this be
> allowed in the kernel?
>
I don't understand why iproute2 and kernel are not sync when it comes to
the max stacked labels, iproute2 should export kernel headers.
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="https://marc.info/?l=linux-netdev&m=146913202123729&w=2">https://marc.info/?l=linux-netdev&m=146913202123729&w=2</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>