On Thu, Oct 10, 2024 at 09:27:27AM -0700, Stephen Hemminger wrote: > On Tue, 10 Sep 2024 10:54:37 +0800 > fengchengwen <fengcheng...@huawei.com> wrote: > > > On 2024/8/14 18:49, Bruce Richardson wrote: > > > Rather than having a single define for maximum queues per ethernet port, > > > we can set the max values for Rx queues and Tx queue independently. This > > > allows future memory saving for apps which only need large numbers of Rx > > > queues or only large numbers of Tx queues. > > > > > > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > > > Acked-by: Morten Brørup <m...@smartsharesystems.com> > > > --- > > > config/rte_config.h | 2 ++ > > > doc/guides/rel_notes/release_24_11.rst | 6 ++++++ > > > 2 files changed, 8 insertions(+) > > > > > > diff --git a/config/rte_config.h b/config/rte_config.h > > > index d67ff77c71..2c11b4eeec 100644 > > > --- a/config/rte_config.h > > > +++ b/config/rte_config.h > > > @@ -65,6 +65,8 @@ > > > > > > /* ether defines */ > > > #define RTE_MAX_QUEUES_PER_PORT 1024 > > > +#define RTE_MAX_ETHPORT_RX_QUEUES 1024 > > > +#define RTE_MAX_ETHPORT_TX_QUEUES 1024 > > > > The Rx Queues != Tx Queues is not a mainstream scenario (at least from most > > of DPDK user as I know), > > rename it (not separate Rx/Tx) with eth meaning and make it as a compile > > option is enough. > > > Agree, allowing max Tx != Rx creates more test cases and other things. > Lets not open up that can of worms.
I fail to see why it would be that problematic requiring additional test cases. I also think it's reasonable to give that level of control - thinking particularly of cases where one side may require thousands of queues e.g. the rte_tm cases with thousands of TX queues - you'll pay a large penalty for the other side's (RX) data-structures unnecessarily. /Bruce
