[Top] [All Lists]

Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3

To: Einar Lück <lkml@xxxxxxxxxxxxxx>
Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Wed, 2 Feb 2005 17:23:33 -0800
Cc: linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <41C6B54F.2020604@xxxxxxxxxxxxxx>
References: <41C6B54F.2020604@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 20 Dec 2004 12:19:43 +0100
Einar Lück <lkml@xxxxxxxxxxxxxx> 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.

<Prev in Thread] Current Thread [Next in Thread>