| 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@davemloft.net> |
| References: | <41C6B54F.2020604@einar-lueck.de> <20050202172333.4d0ad5f0.davem@davemloft.net> <420A1011.1030602@einar-lueck.de> <20050209120157.18dc75c1.davem@davemloft.net> |
| 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 implementation 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. 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? Regards, Einar. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3, David S. Miller |
|---|---|
| Next by Date: | Re: 2.6.10 TCP troubles -- suggested patch, David S. Miller |
| Previous by Thread: | Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3, David S. Miller |
| Next by Thread: | Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |