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>
