[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DB9PR04MB81850CAA8C2AD7CA03D9E76BECA52@DB9PR04MB8185.eurprd04.prod.outlook.com>
Date: Thu, 11 Jul 2024 13:23:53 +0000
From: "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
To: Vladimir Oltean <vladimir.oltean@....com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Breno Leitao <leitao@...ian.org>, Herbert Xu
<herbert@...dor.apana.org.au>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linuxppc-dev@...ts.ozlabs.org"
<linuxppc-dev@...ts.ozlabs.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH net-next 0/5] Eliminate CONFIG_NR_CPUS dependency in
dpaa-eth and enable COMPILE_TEST in fsl_qbman
> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@....com>
> Sent: Thursday, July 11, 2024 2:00 AM
> To: netdev@...r.kernel.org
> Cc: David S. Miller <davem@...emloft.net>; Eric Dumazet
> <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo Abeni
> <pabeni@...hat.com>; Breno Leitao <leitao@...ian.org>; Herbert Xu
> <herbert@...dor.apana.org.au>; Madalin Bucur <madalin.bucur@....com>;
> linux-kernel@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org; linux-arm-
> kernel@...ts.infradead.org
> Subject: [PATCH net-next 0/5] Eliminate CONFIG_NR_CPUS dependency in dpaa-
> eth and enable COMPILE_TEST in fsl_qbman
>
> Breno's previous attempt at enabling COMPILE_TEST for the fsl_qbman
> driver (now included here as patch 5/5) triggered compilation warnings
> for large CONFIG_NR_CPUS values:
> https://lore.kernel.org/all/202406261920.l5pzM1rj-lkp@intel.com/
>
> Patch 1/5 switches two NR_CPUS arrays in the dpaa-eth driver to dynamic
> allocation to avoid that warning. There is more NR_CPUS usage in the
> fsl-qbman driver, but that looks relatively harmless and I couldn't find
> a good reason to change it.
>
> I noticed, while testing, that the driver doesn't actually work properly
> with high CONFIG_NR_CPUS values, and patch 2/5 addresses that.
>
> During code analysis, I have identified two places which treat
> conditions that can never happen. Patches 4/5 and 5/5 simplify the
> probing code - dpaa_fq_setup() - just a little bit.
>
> Finally we have at 5/5 the patch that triggered all of this. There is
> an okay from Herbert to take it via netdev, despite it being on soc/qbman:
> https://lore.kernel.org/all/Zns%2FeVVBc7pdv0yM@gondor.apana.org.au/
>
> Breno Leitao (1):
> soc: fsl: qbman: FSL_DPAA depends on COMPILE_TEST
>
> Vladimir Oltean (4):
> net: dpaa: avoid on-stack arrays of NR_CPUS elements
> net: dpaa: eliminate NR_CPUS dependency in egress_fqs[] and conf_fqs[]
> net: dpaa: stop ignoring TX queues past the number of CPUs
> net: dpaa: no need to make sure all CPUs receive a corresponding Tx
> queue
>
> .../net/ethernet/freescale/dpaa/dpaa_eth.c | 72 +++++++++++--------
> .../net/ethernet/freescale/dpaa/dpaa_eth.h | 20 ++++--
> .../ethernet/freescale/dpaa/dpaa_ethtool.c | 10 ++-
> drivers/soc/fsl/qbman/Kconfig | 2 +-
> 4 files changed, 65 insertions(+), 39 deletions(-)
>
> --
> 2.34.1
For the series,
Acked-by: Madalin Bucur <madalin.bucur@....nxp.com>
Thanks,
Madalin
Powered by blists - more mailing lists