<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 6 April 2017 at 15:36, David Ahern <span dir="ltr"><<a target="_blank" href="mailto:dsa@cumulusnetworks.com">dsa@cumulusnetworks.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">net-next tree has the patch set increasing number of labels. Allows up<br>
to 30 labels for ingress (ip->mpls) and routing (mpls->mpls).<br>
<br>
An mpls_route is limited to 4096 bytes (number of nexthops + labels); an<br>
lwt (ingress) route is under 128 bytes. With the latest set users of<br>
N-labels takes the performance hit of each additional label. </blockquote><div><br></div><div>I think that having 30 stacked labels is useless, regardless of the performance<br>issue, like Jeff said, the worst case covers 5 labels. I don't inderstand this waste.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-HOEnZb"><div class="gmail-h5">
On 3/23/17 1:34 PM, Amine Kherbouche wrote:<br>
> Olivier,<br>
><br>
>     The best for me, is to have the possibility to recompile the MPLS<br>
>     kernel module with the new value the MAX_LABEL_STACK and then let<br>
>     our Segment Routing implementation read this value to determine<br>
>     what's feasible.<br>
><br>
> Yes but we still need a default value.<br>
> You have also to see the perf impact, now the current mpls entry size in<br>
> linux kernel is under<br>
> a cache line, even using 12 stacked labels, we are always under a cache<br>
> line but beyond<br>
> this value we're going to see performance issue.<br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Amine<br></div></div>
</div></div>