Re: [PATCH] ipvs: change ip_vs_conn_tab_bits range to [8,31]

On Wed, Apr 12, 2023 at 01:49:08PM -0700, Abhijeet Rastogi via B4 Relay wrote:
> From: Abhijeet Rastogi <[email protected]>
> 
> Current range [8, 20] is set purely due to historical reasons
> because at the time, ~1M (2^20) was considered sufficient.
> 
> Previous change regarding this limit is here.
> 
> Link: https://lore.kernel.org/all/86eabeb9dd62aebf1e2533926fdd13fed48bab1f.1631289960.git.aclaudi@redhat.com/T/#u
> 
> Signed-off-by: Abhijeet Rastogi <[email protected]>
> ---

Hi Abhijeet,

> The conversation for this started at: 
> 
> https://www.spinics.net/lists/netfilter/msg60995.html

  'The 20 bit (1m entries) ceiling exists since the original merge of ipvs
   in 2003, so likely this was just considered "big enough" back then.'

Yes, that matches my recollection.

There were probably also concerns about the viability of making
larger allocations at the time on the kinds of systems where
IPVS would be deployed.

On the allocation theme, I do note that 2^31 does lead to a substantial
vmalloc allocation regardless of actual usage. Probably it would be best
to move IPVS to use rhashtable(). But that is obviously a much more
invasive change.

In any case, I think this patch is an improvement on the current situation.

Acked-by: Simon Horman <[email protected]>

> 
> The upper limit for algo is any bit size less than 32, so this
> change will allow us to set bit size > 20. Today, it is common to have
> RAM available to handle greater than 2^20 connections per-host.
> 
> Distros like RHEL already have higher limits set.

...