[frr] 2 MPLS Questions

[Donald Sharp]

I'm not sure I would call it 'waste'.  The solution, as I understand
it, allocates the appopriate amount of memory to handle the # of
labels handed to it with a *limit* of 4k bytes to the size that is
alloc'ed internally to the kernel.  This way they are keeping the data
structure limit to the maximum size of a page on some platforms at
worse case.

donald

On Thu, Apr 6, 2017 at 10:09 AM, Amine Kherbouche
<amine.kherbouche at 6wind.com> wrote:
>
>
> On 6 April 2017 at 15:36, David Ahern <dsa at cumulusnetworks.com> wrote:
>>
>> net-next tree has the patch set increasing number of labels. Allows up
>> to 30 labels for ingress (ip->mpls) and routing (mpls->mpls).
>>
>> An mpls_route is limited to 4096 bytes (number of nexthops + labels); an
>> lwt (ingress) route is under 128 bytes. With the latest set users of
>> N-labels takes the performance hit of each additional label.
>
>
> I think that having 30 stacked labels is useless, regardless of the
> performance
> issue, like Jeff said, the worst case covers 5 labels. I don't inderstand
> this waste.
>
>>
>> On 3/23/17 1:34 PM, Amine Kherbouche wrote:
>> > Olivier,
>> >
>> >     The best for me, is to have the possibility to recompile the MPLS
>> >     kernel module with the new value the MAX_LABEL_STACK and then let
>> >     our Segment Routing implementation read this value to determine
>> >     what's feasible.
>> >
>> > Yes but we still need a default value.
>> > You have also to see the perf impact, now the current mpls entry size in
>> > linux kernel is under
>> > a cache line, even using 12 stacked labels, we are always under a cache
>> > line but beyond
>> > this value we're going to see performance issue.
>> >
>
>
>
>
> --
> Amine