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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87shm1np5h.fsf@xmission.com>
Date:   Sat, 25 Mar 2017 14:15:54 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     David Ahern <dsa@...ulusnetworks.com>
Cc:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        rshearma@...cade.com
Subject: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route

David Ahern <dsa@...ulusnetworks.com> writes:

> Bump the maximum number of labels for MPLS routes from 2 to 12. To keep
> memory consumption in check the labels array is moved to the end of mpls_nh
> and mpls_iptunnel_encap structs as a 0-sized array. Allocations use the
> maximum number of labels across all nexthops in a route for LSR and the
> number of labels configured for LWT.
>
> The mpls_route layout is changed to:
>
>    +----------------------+
>    | mpls_route           |
>    +----------------------+
>    | mpls_nh 0            |
>    +----------------------+
>    | alignment padding    |   4 bytes for odd number of labels; 0 for even
>    +----------------------+
>    | via[rt_max_alen] 0   |
>    +----------------------+
>    | alignment padding    |   via's aligned on sizeof(unsigned long)
>    +----------------------+
>    | ...                  |
>
> Meaning the via follows its mpls_nh providing better locality as the
> number of labels increases. UDP_RR tests with namespaces shows no impact
> to a modest performance increase with this layout for 1 or 2 labels and
> 1 or 2 nexthops.
>
> The new limit is set to 12 to cover all currently known segment
> routing use cases.

How does this compare with running the packet a couple of times through
the mpls table to get all of the desired labels applied?

I can certainly see the case in an mpls tunnel ingress where this might
could be desirable.    Which is something you implement in your last
patch.  However is it at all common to push lots of labels at once
during routing?

I am probably a bit naive but it seems absurd to push more
than a handful of labels onto a packet as you are routing it.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ