[Top] [All Lists]

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

To: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
From: Einar Lück <lkml@xxxxxxxxxxxxxx>
Date: Wed, 09 Feb 2005 21:23:57 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20050209120157.18dc75c1.davem@xxxxxxxxxxxxx>
References: <41C6B54F.2020604@xxxxxxxxxxxxxx> <20050202172333.4d0ad5f0.davem@xxxxxxxxxxxxx> <420A1011.1030602@xxxxxxxxxxxxxx> <20050209120157.18dc75c1.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
David S. Miller wrote:

So essentially you want per-flow multipathing.  Except that you're 
is over-optimizing it to the point where it's only per-flow for your specific
case where the connections are short lived and high rate.

This hurts long lasting connections.

So I'm pretty much against this change.  Do it right by making it occur
per-connection attempt, it's not my problem to figure out how to do that
efficiently, it's your's :-)

We do not want per-flow multipathing. We want per connection multipathing with 
fast route lookups (that's why we have all routes in the cache). That is 
exactly what we implemented. Our tests prove that a connection keeps its route 
as long as it lives (the dstentry remains associated with the socket). That's 
why I do not really
understand why our approach hurts long lasting connections in any way. Can you 
explain your point more precisely?


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