On Wed, 09 Feb 2005 21:42:39 +0100
Einar Lück <[EMAIL PROTECTED]> wrote:
> We considered the routing case: in the routing case ip_route_input is called.
> In this case we just select the first route in the cache which is always the
> same
> (we ensure that). Consequently, the routing behaviour
David S. Miller wrote:
This was brought up before. It's the case where the system is acting
as a router, you have to consider that case and not just the one where
the local system is where the connections are originating from.
Your trick only works because of how routes are cached per-socket.
On Wed, 09 Feb 2005 21:23:57 +0100
Einar Lück <[EMAIL PROTECTED]> wrote:
> 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
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.
This hurts long lasting connections.
So I'm pretty much
On Wed, 09 Feb 2005 14:28:49 +0100
Einar Lück <[EMAIL PROTECTED]> wrote:
> The scenarios we have in mind are setups in which a set of collaborating
> servers steadly establish connections among each other with a very high rate.
> This high rate requirement drove us to consider the inclusion of
David S. Miller wrote:
Can you describe more precisely "the scenerios, that are relevant
to us"?
The scenarios we have in mind are setups in which a set of collaborating
servers steadly establish connections among each other with a very high rate.
This high rate requirement drove us to consider
David S. Miller wrote:
Can you describe more precisely the scenerios, that are relevant
to us?
The scenarios we have in mind are setups in which a set of collaborating
servers steadly establish connections among each other with a very high rate.
This high rate requirement drove us to consider
On Wed, 09 Feb 2005 14:28:49 +0100
Einar Lück [EMAIL PROTECTED] wrote:
The scenarios we have in mind are setups in which a set of collaborating
servers steadly establish connections among each other with a very high rate.
This high rate requirement drove us to consider the inclusion of all
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.
This hurts long lasting connections.
So I'm pretty much
On Wed, 09 Feb 2005 21:23:57 +0100
Einar Lück [EMAIL PROTECTED] wrote:
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
David S. Miller wrote:
This was brought up before. It's the case where the system is acting
as a router, you have to consider that case and not just the one where
the local system is where the connections are originating from.
Your trick only works because of how routes are cached per-socket.
On Wed, 09 Feb 2005 21:42:39 +0100
Einar Lück [EMAIL PROTECTED] wrote:
We considered the routing case: in the routing case ip_route_input is called.
In this case we just select the first route in the cache which is always the
same
(we ensure that). Consequently, the routing behaviour is
On Mon, 20 Dec 2004 12:19:43 +0100
Einar Lück <[EMAIL PROTECTED]> 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
On Mon, 20 Dec 2004 12:19:43 +0100
Einar Lück [EMAIL PROTECTED] 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
14 matches
Mail list logo
