We propose the attached and the subsequent patch for an extension
of the existing multipath capabilities. These patches are partly
extended versions of patches posted last week as RFC. (Please
refer to the corresponding mails for details about their purpose).
There are the following changes and additions for which we hope
you have comments on:
* a _weighted_ random routing policiy utilizing the weights
configurable via "ip route" that allows to approximate many other policies
(e.g. round robin)
* a routing policy choosing routes with equal probability without
any state maintenance overhead(=> low delay)
* a simple round robin policy
* the extended behaviour is only optionally compiled in to allow for
the utilization of the old behaviour (as David Miller denoted: there
are scenarios/setups in which the old behaviour is more desirable
than the new behaviour)
* the ip_route_input lookup function does not consider more than
one alternative, only ip_route_output_key does (as Jamal denoted:
our extension makes primarily sense if one routes on a per
connection basis as we do in ip_route_output_key and not on a per
"packet" basis as we do in the ip forwarding case)
* an interface round robin policy that selects among relevant routes
in a way that tries to ensure an overall round robin among the
available _interfaces_ is achieved.

In addition to any opinions about the above mentioned changes we would
be very glad about any comments on the following issue:
Is it desirable to introduce modules for the policy implementations? We 
think
the weighted random policy is the most relevant one in this context as it
allows for the rough emulation of all other policies and considers the
weights configured via "ip route". Anyway,  the other policies are more
efficient than their emulated counterparts.  Up to now, as we are not sure,
wether more policies than weighted random are desired, one has to decide
via kernel configuration, which implementation should be utilized.

Further remarks on the organisation of the patch:
* the patch attached to this mail splits up ip_route_(input|output)_slow
(identical to the one posted last week as it still fits to bitkeeper head)
* the patch following in the subsequent mail encompasses the changes
mentioned above on the basis of the splitting patch

Regards,
Einar