LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH net 0/8] IPVS fixes for net

To: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>, Julian Anastasov <ja@xxxxxx>
Subject: Re: [PATCH net 0/8] IPVS fixes for net
Cc: netfilter-devel@xxxxxxxxxxxxxxx, davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, kuba@xxxxxxxxxx, pabeni@xxxxxxxxxx, edumazet@xxxxxxxxxx, fw@xxxxxxxxx, horms@xxxxxxxxxx, lvs-devel@xxxxxxxxxxxxxxx, Anna-Maria Behnsen <anna-maria@xxxxxxxxxxxxx>, Frederic Weisbecker <frederic@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxx>
From: Waiman Long <longman@xxxxxxxxxx>
Date: Tue, 12 May 2026 21:41:38 -0400
On 5/6/26 11:16 AM, Pablo Neira Ayuso wrote:
Hi Julian,

Cc'ing Waiman Long and NOHZ maintainers (apologies if this is dragging
more people that I should into this issue).

On Wed, May 06, 2026 at 11:56:05AM +0300, Julian Anastasov wrote:
[...]
        Here are some comments after the last review from
Sashiko:

https://sashiko.dev/#/patchset/20260505001648.360569-1-pablo%40netfilter.org

Patch 1:
- while ip_vs_dst_event() should loop and ensure all dev
references are released, single change of svc_table_changes
does not indicate the old references are dropped by ip_vs_flush() or
ip_vs_del_service(). I'll post new change to abort the loop
when we are sure the services are at least once released.

Patch 5:
- after executing ip_vs_est_calc_phase(), data can
remain only for kt0 because all estimators are stopped,
unlinked and the kt data structures for kt > 0 are empty
and as result freed and the kthread tasks stopped (which
happens early). After this, kt 0 calls
ip_vs_est_drain_temp_list() as part of its loop,
so it will eventually call ip_vs_est_add_kthread()
and ip_vs_est_reload_start() to request kthread tasks
to be started if data for new kthreads are created.
So, I don't see problem here.

Patch 6:
- we will add conn_max sysctl soon
OK, just follow up on these for 1 and 6, thanks.

Patch 7 and 8:
- I can not decide how valid are the concerns in the review.
Placing here links for convenience:

https://sashiko.dev/#/message/20260505001648.360569-8-pablo%40netfilter.org
https://sashiko.dev/#/message/20260505001648.360569-9-pablo%40netfilter.org

This is away from my limited scope of knowledged.

Sorry for the late reply. The latest upstream kernel has already been updated to make kthreads follow HK_TYPE_DOMAIN in determining which non-housekeeping CPUs should be avoided. For full CPU isolation, users should set nohz_full, isolcpus=domain and isolcpus=managed_irq to specify CPUs to isolate. Just one of them isn't enough for CPU isolation. In fact, the current plan is to enable runtime modification to these CPU isolation features so that users can acquire additional isolated CPUs or release some of them on demand. This is still a work in progress. So the AI comment on patch 8 isn't a real concern.

Please let me know if you have additional question.

Cheers,
Longman



<Prev in Thread] Current Thread [Next in Thread>