[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zizbczvz.fsf@x220.int.ebiederm.org>
Date: Wed, 21 Oct 2015 23:04:32 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Roopa Prabhu <roopa@...ulusnetworks.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, rshearma@...cade.com
Subject: Re: [PATCH net-next v4 0/2] mpls: multipath support
Roopa Prabhu <roopa@...ulusnetworks.com> writes:
> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>
> This patch adds support for MPLS multipath routes.
>
> Includes following changes to support multipath:
> - splits struct mpls_route into 'struct mpls_route + struct mpls_nh'.
>
> - struct mpls_nh represents a mpls nexthop label forwarding entry
>
> - Adds support to parse/fill RTA_MULTIPATH netlink attribute for
> multipath routes similar to ipv4/v6 fib
>
> - In the process of restructuring, this patch also consistently changes all
> labels to u8
>
> $ip -f mpls route add 100 nexthop as 200 via inet 10.1.1.2 dev swp1 \
> nexthop as 700 via inet 10.1.1.6 dev swp2 \
> nexthop as 800 via inet 40.1.1.2 dev swp3
>
> $ip -f mpls route show
> 100
> nexthop as to 200 via inet 10.1.1.2 dev swp1
> nexthop as to 700 via inet 10.1.1.6 dev swp2
> nexthop as to 800 via inet 40.1.1.2 dev swp3
>
> Roopa Prabhu (1):
> mpls: multipath support
>
> Robert Shearman (1):
> mpls: flow-based multipath selection
>
> Signed-off-by: Roopa Prabhu <roopa@...ulusnetworks.com>
>
> ----
> v2:
> - Incorporate some feedback from Robert:
> use dynamic allocation (list) instead of static allocation
> for nexthops
> v3:
> - Move back to arrays (same as v1), also suggested by Eric Biederman
>
> v4:
> - address a few comments from Eric Biederman
> Plan to address the following pending comments in incremental patches after this
> infrastructure changes go in.
> - Move VIA size to 16 bytes
> - use ipv6 flow label in ecmp calculations
> - dead route handling during multipath route selection (I had planned this in
> an incremental patch initially).
I don't see anything problematic in the patches the worst
I found is dead code and we can delete that later so
for purposes of moving forward I say:
Acked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
That said we really need dead path handling. Without handling paths
that go dead this functionality really is pretty much broken. So if you
can't get that by the merge window we will need to apply a patch to
disable processing of the RTA_MULTIPATH netlink attribute.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists