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

[Waiman Long <longman@redhat.com>]

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