On Thu, May 12, 2022 at 6:33 PM Julian Anastasov <ja@xxxxxx> wrote: > > > 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. > Yes, we need a more nice way to do this work. It's easy for RR, but a little complex for WRR, after I figure out how WRR works. > 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. > Using a user tool to add dests in random order is an option, which I thought about before. But it needs users to make some extra changes. Thanks for your explanation. The options you mentioned are mature and significant. I'll make them together and try to find the best way, after I dig into the ipvs code deeper. > 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. > Yeah, it seems that the range of the lock can be reduced. I think I'm able to handle it. > > 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> >
