netdev - Re: [PATCH net-next iproute2] ip: increase number of MPLS labels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <70667d3a-5cbc-4900-3c41-bce508a057ac@cumulusnetworks.com>
Date:   Mon, 1 May 2017 15:22:06 -0600
From:   David Ahern <dsa@...ulusnetworks.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org, roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net-next iproute2] ip: increase number of MPLS labels

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.

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.