On Fri, Oct 17, 2025 at 04:35:18PM +0200, Alexander Lobakin wrote: > From: Michal Swiatkowski <[email protected]> > Date: Fri, 17 Oct 2025 09:30:44 +0200 > > > On Fri, Oct 17, 2025 at 07:03:31AM +0200, Przemek Kitszel wrote: > >> On 10/16/25 17:36, Alexander Lobakin wrote: > >>> From: Michal Swiatkowski <[email protected]> > >>> Date: Thu, 16 Oct 2025 08:22:50 +0200 > >>> > >>>> On some high-core systems loading ice driver with default values can > >>>> lead to queue/irq exhaustion. It will result in no additional resources > >>>> for SR-IOV. > >>>> > >>>> In most cases there is no performance reason for more than 64 queues. > >>>> Limit the default value to 64. Still, using ethtool the number of > >>>> queues can be changed up to num_online_cpus(). > >>>> > >>>> This change affects only the default queue amount on systems with more > >>>> than 64 cores. > >>>> > >>>> Reviewed-by: Jacob Keller <[email protected]> > >>>> Signed-off-by: Michal Swiatkowski <[email protected]> > >>>> --- > >>>> drivers/net/ethernet/intel/ice/ice.h | 20 ++++++++++++++++++++ > >>>> drivers/net/ethernet/intel/ice/ice_irq.c | 6 ++++-- > >>>> drivers/net/ethernet/intel/ice/ice_lib.c | 8 ++++---- > >>>> 3 files changed, 28 insertions(+), 6 deletions(-) > >>>> > >>>> diff --git a/drivers/net/ethernet/intel/ice/ice.h > >>>> b/drivers/net/ethernet/intel/ice/ice.h > >>>> index 3d4d8b88631b..354ec2950ff3 100644 > >>>> --- a/drivers/net/ethernet/intel/ice/ice.h > >>>> +++ b/drivers/net/ethernet/intel/ice/ice.h > >>>> @@ -1133,4 +1133,24 @@ static inline struct ice_hw > >>>> *ice_get_primary_hw(struct ice_pf *pf) > >>>> else > >>>> return &pf->adapter->ctrl_pf->hw; > >>>> } > >>>> + > >>>> +/** > >>>> + * ice_capped_num_cpus - normalize the number of CPUs to a reasonable > >>>> limit > >>>> + * > >>>> + * This function returns the number of online CPUs, but caps it at > >>>> suitable > >>>> + * default to prevent excessive resource allocation on systems with > >>>> very high > >>>> + * CPU counts. > >>>> + * > >>>> + * Note: suitable default is currently at 64, which is reflected in > >>>> default_cpus > >>>> + * constant. In most cases there is no much benefit for more than 64 > >>>> and it is a > >>>> + * power of 2 number. > >>>> + * > >>>> + * Return: number of online CPUs, capped at suitable default. > >>>> + */ > >>>> +static inline u16 ice_capped_num_cpus(void) > >>>> +{ > >>>> + const int default_cpus = 64; > >>> > >>> Maybe we should just use netif_get_num_default_rss_queues() like I did > >>> in idpf? > >>> > >>> Or it still can be too high e.g. on clusters with > 256 CPUs? > >> > >> good point, > >> perhaps we should both use it and change the (kernel) func to cap at 64 > >> > > > > Sounds good, thanks for pointing the function. > > > > Do you think it is ok to cap the generic function? Maybe other vendors > > want more default queues. > > Nah I don't think it's a good idea to hardcode any numbers in the > generic function. > > > > > What about capping netif_get_num_default_rss_queues() at 64 just for > > ice? > > netif_get_num_default_rss_queues() returns *half* of the number of > *physical* cores. I.e. it will return something bigger than 64 only in > case of > 256 threads in the system (considering SMT). > > Do we need to still cap this to 64 in ice at all?
That can be good enough. I will send next version with just call to this function. > > Thanks, > Olek
