On Thu, Mar 30, 2000 at 11:47:04AM +0200, George Bonser wrote:
> It must be even worse than that because to balance, I must be assured that
> when I drop a route from the cache, the next lookup of that destination
> gets the other route. I mean, if I simply scan the routing table and find
> a route, what prevents me from finding the same route the next time I scan
> the table? Doesn't the route I found last time need to be moved to the end
> of the table so I find the alternative route the next time? Or does it
> shomehow remember which route it found last time and skips it to search
> for the other?
The equalize patch uses a random generator to avoid this problem.
>
> Maybe a way to do it is not to cache routes, but cache destinations that
[...]
Of course it is implementable somehow, the question is just whether
it is worth the additional complexity in the routing code.
My feeling is that if you want route based load distribution extend
teql to equalize based on a packet mark, compute this mark based on
the routing table (that already exists for diffserv/CBQ purposes),
and write a nice frontend that generates teql/route pairs.
It'll probably give better results that using the routing cache,
because it defers the decision about which device to send to to the
latest possible moment when you see the queue lengths. Routing cache
selection occurs when the packet comes in/is generated locally instead,
which is too early.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:26 EST