> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
>
> On Mon, Aug 12, 2024 at 04:10:49PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@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.
ACK.
>
> >
> > > # 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.
ACK. And agree about two-patch series.
>
> >
> > 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.
I would guess that many applications have an asymmetrical split of number of
RX/TX queues. So I would argue that:
The reason to make this configurable in meson is to conserve memory, so why
only go half the way if there is more memory to be conserved?
The distros will use oversize maximums anyway, but custom built applications
might benefit.
Here's a weird thought:
Perhaps RX and TX maximums can be controlled individually by changing
rte_config.h, and they can be overridden via one meson configuration parameter
to set both (to the same value).
>
> >
> > With suggested changes (splitting RX/TX maximums not required),
> > Acked-by: Morten Brørup <m...@smartsharesystems.com>
> >
My ACK remains; splitting RX/TX maximums is not Must Have, it is Nice To Have.
