public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Peter Nørlund" <pch@ordbogen.com>
Cc: netdev@vger.kernel.org
Subject: Re: ipv4: add hash-based multipath routing
Date: Mon, 13 Apr 2015 09:34:46 -0700	[thread overview]
Message-ID: <20150413093446.438bca5e@urahara> (raw)
In-Reply-To: <20150412205430.6d7fcd30@tyr>

On Sun, 12 Apr 2015 20:54:30 +0200
Peter Nørlund <pch@ordbogen.com> wrote:

> Hi all,
> 
> I'm working on adding L3/L4 hash-based IPv4 multipath to the kernel,
> but I wonder what the best approach for the mainline kernel is.
> 
> When the IPv6 multipath code was added, choosing the routing algorithm
> by means of compile-time config or sysctl was rejected, so I assume
> that we want to revive the RTA_MP_ALGO or a new attribute?
> 
> The IPv6 multipath uses L4 balancing - which is fine for IPv6 where
> fragmentation does not happend - but in my opinion the safest default
> for IPv4 is L3, especially when multipath is used together with anycast.
> 
> My main problem is the existing multipath code which is really old
> (linux 2.1.66). From the looks of it, it attempts to be somewhat random,
> but in reality it is more or less weighted round-robin, and as far as I
> can tell it even has an off-by-one error in its handling of the random
> value. I think it is wise to support L3, L4, and per-packet
> load-balancing, just like the hardware vendors, but must the per-packet
> load-balancing be default, or is it okay to change the default
> behavior? Also, would a weighted round-robin with a single per-cpu
> counter suffice? This would get rid of the spinlock and avoid causing
> cache invalidations of the route info with each packet. But it would not
> be true round-robin, which would require a per-route-info counter. If
> we are promising round-robin it is bad, but if we are simply promising
> weighted per-packet load-balancing, it's a different matter.

We (Brocade) did some work on this, but it never was done enough to
submit upstream. The ideal is to allow configuring choice of algorithm
per-route.

      reply	other threads:[~2015-04-13 16:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-12 18:54 ipv4: add hash-based multipath routing Peter Nørlund
2015-04-13 16:34 ` Stephen Hemminger [this message]

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=20150413093446.438bca5e@urahara \
    --to=stephen@networkplumber.org \
    --cc=netdev@vger.kernel.org \
    --cc=pch@ordbogen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox