All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Shearman <rshearma@brocade.com>
To: Roopa Prabhu <roopa@cumulusnetworks.com>, <davem@davemloft.net>
Cc: <ebiederm@xmission.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 0/3] mpls: multipath support
Date: Wed, 12 Aug 2015 18:30:14 +0100	[thread overview]
Message-ID: <55CB82A6.8070800@brocade.com> (raw)
In-Reply-To: <1439329548-50935-1-git-send-email-roopa@cumulusnetworks.com>

On 11/08/15 22:45, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch series adds multipath support to mpls routes.
>
> resembles ipv4 multipath support. The multipath route nexthop
> selection algorithm is the same code as in ipv4 fib code.
>
> I understand that the multipath algorithm in ipv4 is undergoing
> some changes and will move mpls to similar algo if applicable once
> those get merged.

Is it necessary for the mpls patch selection algorithm to closely 
resemble the ipv4 one? A flow based algorithm would be much better for 
traffic that is sensitive to re-ordering (e.g TCP, L2VPN) and IMHO we 
should do this from the start for MPLS.

I've also been looking at implementing this functionality. I've got a 
set of patches for this that I can send if you'd like.

>
> mpls multipath support can be moved under CONFIG_MPLS_ROUTE_MULTIPATH if
> needed similar to CONFIG_IP_ROUTE_MULTIPATH. I started with that
> but that resulted in too many #ifdef CONFIG_MPLS_ROUTE_MULTIPATH
> throughout the af_mpls code. If there is a strong reason
> to introduce a config option, I will respin v2 with
> CONFIG_MPLS_ROUTE_MULTIPATH. These multipath patches do not introduce
> any UAPI changes.

I agree with not having such a config option - I can't see a strong 
reason for it.

Thanks,
Rob

>
> example iproute2 usage:
> $ip -f mpls route add 100 nexthop as 200 via inet 10.1.1.2 dev swp1 \
> 	nexthop as 300 via inet 10.1.1.6 dev swp2
>
> $ip -f mpls route show
> 100
> 	nexthop as to 200 via inet 10.1.1.2  dev swp1
> 	nexthop as to 300 via inet 10.1.1.6  dev swp2
>
>
> Roopa Prabhu (3):
>    mpls: move mpls_route nexthop fields to a new nhlfe struct
>    mpls: consistently use u8 to store number of labels
>    mpls: add multipath route support
>
>   include/net/mpls_iptunnel.h |    2 +-
>   net/mpls/af_mpls.c          |  519 ++++++++++++++++++++++++++++++++-----------
>   net/mpls/internal.h         |   44 +++-
>   3 files changed, 437 insertions(+), 128 deletions(-)
>

  reply	other threads:[~2015-08-12 17:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-11 21:45 [PATCH net-next 0/3] mpls: multipath support Roopa Prabhu
2015-08-12 17:30 ` Robert Shearman [this message]
2015-08-13  2:07   ` roopa
2015-08-13 13:46     ` Robert Shearman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55CB82A6.8070800@brocade.com \
    --to=rshearma@brocade.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.