David Ahern [off-list ref] writes:

On 5/1/17 3:03 PM, Eric W. Biederman wrote:

quoted

Basically the kernel maximum is how large we can make struct mpls_route
without while being < 4096 aka PAGE_SIZE.  Which also happens to be
larger than the largest known consumer.

2 limits in the kernel:
1. max allocation for mpls_route of 4096
2. max number of labels of 30.

Ah yes. I remember now.  That conversation was just long enough ago that
the details had slipped my mind.

The latter was necessitated by the LWT path. I wanted a cap on it and
for the cap to be consistent for both ingress and LSP. To that end I
went with a maximum of 30 labels in the kernel: 4k max allocation = ~30
labels per nexthop with ~30 nexthops. For both 30 is excessive, overkill
number. (though someone did ask me recently why not 512 labels. seriously)

I can't say it makes sense for iproute2 to support 30 labels.
Argumentative that even 16 is too high, but some folks have argued for it.

quoted

Dave is there a practical reason that is motivating increasing the size
in iproute?  Or is the desire to ensure that iproute can take full
advantage of the kernel?

I suspect only routing daemons would inject a high label stack. It would
be nice for iproute2 to 1. be able to print that route properly
(currently does not if the label count exceeds what it can handle), 2.
be able to reinject the route. Even with scripting creating a route
using ip with a lot of labels is a PITA.

Yes.  At this point I will agree with Stephen Hemminger.  The sensible
change to iproute is to rework the code so that it supports an arbitrary
number of labels.  At least up to iproutes fixed sized rtnetlink packet
buffers.

It is a bit more work but then iproute won't be something that needs
worrying about any more.  It will just work with whatever size addresses
are thrown at it.

Eric