Hello, On Thu, 8 Dec 2022, Pablo Neira Ayuso wrote: > On Thu, Dec 08, 2022 at 01:06:14PM +0100, Pablo Neira Ayuso wrote: > > On Tue, Nov 22, 2022 at 06:45:58PM +0200, Julian Anastasov wrote: > > > Hello, > > > > > > This patchset implements stats estimation in kthread context. > > > It replaces the code that runs on single CPU in timer context every > > > 2 seconds and causing latency splats as shown in reports [1], [2], [3]. > > > The solution targets setups with thousands of IPVS services, destinations > > > and multi-CPU boxes. > > > > Series applied to nf-next, thanks. > > Oh wait. I have to hold this back, I have a fundamental question: > > [PATCHv7 4/6] ipvs: use kthreads for stats estimation > > uses kthreads, these days the preferred interface for this is the > generic workqueue infrastructure. > > Then, I can see patch: > > [PATCHv7 5/6] ipvs: add est_cpulist and est_nice sysctl vars > > allows for CPU pinning which is also possible via sysfs. > > Is there any particular reason for not using the generic workqueue > infrastructure? I could not find a reason in the commit logs. The estimation can take long time when using multiple IPVS rules (eg. millions estimator structures) and especially when box has multiple CPUs due to the for_each_possible_cpu usage that expects packets from any CPU. With est_nice sysctl we have more control how to prioritize the estimation kthreads compared to other processes/kthreads that have latency requirements (such as servers). As a benefit, we can see these kthreads in top and decide if we will need some further control to limit their CPU usage (max number of structure to estimate per kthread). Regards -- Julian Anastasov <ja@xxxxxx>
