Messages in this thread | | | Date | Thu, 30 Mar 2000 12:35:58 +0200 | From | Andi Kleen <> | Subject | Re: iproute and 2.3 question |
| |
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/
| |