|
Hello,
On Thu, 12 May 2022, Menglong Dong wrote:
> Yeah, WLC and MH are excellent schedulers. As for SH, my
> fellows' feedback says that it doesn't work well. In fact, it's their
> fault, they just forget to enable port hash and just use the
> default ip hash. With my direction, this case is solved by sh.
>
> Now, I'm not sure if this feature is necessary. Maybe someone
> needs it? Such as someone, who need RR/WRR and a random
> start......
If there is some more clever way to add randomness.
The problem is that random start should be applied after
initial configuration only. But there is no clear point between
where configuration is completed and when service starts.
This is not bad for RR but is bad for WRR.
One way would be the user tool to add dests in random
order. IIRC, this should not affect setups with backup servers
as long as they share the same set of real servers, i.e.
order in svc->destinations does not matter for SYNC but
the real servers should be present in all directors.
Another option would be __ip_vs_update_dest() to
use list_add_rcu() or list_add_tail_rcu() per dest depending
on some switch that enables random ordering for the svc.
But it will affect only schedulers that do not order
later the dests. So, it should help for RR, WRR (random
order per same weight). In this case, scheduler's code
is not affected.
For RR, the scheduler does not use weights and
dests are usually not updated. But for WRR the weights
can be changed and this affects order of selection without
changing the order in svc->destinations.
OTOH, WRR is a scheduler that can support frequent
update of dest weights. This is not true for MH which can
easily change only between 0 and some fixed weight without
changing its table. As result, ip_vs_wrr_dest_changed()
can be called frequently even after the initial configuration,
at the same time while packets are scheduled.
When you mentioned that ip_vs_wrr_gcd_weight() is
slow, I see that ip_vs_wrr_dest_changed() can be improved
to reduce the time while holding the lock. May be
in separate patch we can call ip_vs_wrr_gcd_weight() and
ip_vs_wrr_max_weight() before the spin_lock_bh() by using
two new tmp vars.
> Anyway, I have made a V3 according to your advice. I can
> send it with any positive reply :/
You can use [RFC tag] for this, so that we can
at least review it and further decide what can be done.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
