Re: [RFC PATCH] config: make queues per port a meson config option

[Bruce Richardson <bruce.richardson@intel.com>]

On Mon, Aug 12, 2024 at 04:10:49PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > 
> > The default number of ethernet queues per port is currently set to
> > 1k which is more than enough for most applications, but still is lower
> > than the total number of queues which may be available on modern NICs.
> > Rather than increasing the max queues further, which will increase
> > the memory footprint (since the value is used in array dimensioning),
> > we can instead make the value a meson tunable option - and reduce the
> > default value to 256 in the process.
> 
> Overall, I agree that this tunable is not very exotic, and can be exposed as suggested.
> The reduction of the default value must be mentioned in the release notes.
> 

Yes, good point. I'll add that in any next version.

> 
> >  # set other values pulled from the build options
> >  dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
> > +dpdk_conf.set('RTE_MAX_QUEUES_PER_PORT',
> > get_option('max_queues_per_ethport'))
> 
> Please rename RTE_MAX_QUEUES_PER_PORT to _PER_ETHPORT, so it resembles MAX_ETHPORTS. For API backwards compatibility, you can add:
> #define RTE_MAX_QUEUES_PER_PORT RTE_MAX_QUEUES_PER_ETHPORT
> 

Agree that would more consistent. That would probably best be a separate
patch, since we'd want to convert all internal use over. Will make this a
two-patch set in next version.

> 
> I wonder if it would be possible to have separate max sizes for RX and TX queues? If it can save a non-negligible amount of memory, it might be useful for some applications.
> 

That is an interesting idea. It would certainly allow saving memory for
use-cases where you want a large number of rx queues only, or tx queues
only. However, the defaults are still likely to remain the same. The main
issue I would have with it, is that it would mean having two build time
options rather than 1, and I'm a bit concerned at the number of options we
seem to be accumulating in DPDK.

Overall, I'm tending towards suggesting that we not do that split, but I'm
open to being convinced on it.

> 
> With suggested changes (splitting RX/TX maximums not required),
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>