David Ahern <d...@cumulusnetworks.com> writes: > On 5/1/17 3:03 PM, Eric W. Biederman wrote: >> 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. > > >> 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
