From: "David S. Miller" <davem@davemloft.net>
To: "Einar Lück" <lkml@einar-lueck.de>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
Date: Wed, 2 Feb 2005 17:23:33 -0800 [thread overview]
Message-ID: <20050202172333.4d0ad5f0.davem@davemloft.net> (raw)
In-Reply-To: <41C6B54F.2020604@einar-lueck.de>
On Mon, 20 Dec 2004 12:19:43 +0100
Einar Lück <lkml@einar-lueck.de> wrote:
> This patch is an approach towards solving some problems with the
> current multipath implementation:
> * routing cache allows only one route to be cached for a certain
> search key
> * a mulitpath/load balancing decision is only made in case a
> corresponding route is not yet cached
> In the scenarios, that are relevant to us (high amount of outgoing
> connection requests), this is a serious problem.
I agree that per-connection attempt a new multipath decision
should be made, but within a flow I disagree.
This needs to be flow based.
Can you describe more precisely "the scenerios, that are relevant
to us"?
If you are only interested in more precise multipathing when TCP
connections on the local system are made, this we can implement
via a flag to the ipv4 routing cache which forces a new multipath
decision when TCP sockets have their identity established.
We have a precise interface that is invoked at this time, called
ip_route_connect(). So that is where we would pass in some flag
to indicate that we desire the new multipath behavior.
If you want this behavior on a router, you will need to mark the
packets using something like firewall marking on the SKB, then this
mark would be used at route cache lookup time to determine what
kind of multipath decisions to make.
There is no way we can enable the new behavior for every routing
cache lookup.
next prev parent reply other threads:[~2005-02-03 1:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-20 11:19 [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3 Einar Lück
2004-12-20 15:10 ` Einar Lück
2005-02-03 1:23 ` David S. Miller [this message]
2005-02-09 13:28 ` Einar Lück
2005-02-09 20:01 ` David S. Miller
2005-02-09 20:23 ` Einar Lück
2005-02-09 20:30 ` David S. Miller
2005-02-09 20:42 ` Einar Lück
2005-02-09 21:17 ` David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2004-12-20 11:15 Einar Lück
2004-12-20 11:13 Einar Lück
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=20050202172333.4d0ad5f0.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@einar-lueck.de \
--cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).