netdev - Re: [PATCH net 2/2] net: stmmac: Limit the number of MTL queues to maximum value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2d88c997-f417-4fd0-a871-a9af4a28213e@socionext.com>
Date: Thu, 16 Jan 2025 19:02:08 +0900
From: Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>
To: Furong Xu <0x1207@...il.com>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Jose Abreu <joabreu@...opsys.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 2/2] net: stmmac: Limit the number of MTL queues to
 maximum value

Hi Furong,

Thank you for your comment.

On 2025/01/16 12:28, Furong Xu wrote:
> On Thu, 16 Jan 2025 11:08:53 +0900, Kunihiko Hayashi
> <hayashi.kunihiko@...ionext.com> wrote:
> 
>> The number of MTL queues to use is specified by the parameter
>> "snps,{tx,rx}-queues-to-use" from the platform layer.
>>
>> However, the maximum number of queues is determined by
>> the macro MTL_MAX_{TX,RX}_QUEUES. It's appropriate to limit the
>> values not to exceed the upper limit values.
>>
> 
> The Fixes: tag is required too.

I see. I'll find it.

>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>
>> ---
>>   drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> index ad868e8d195d..471eb1a99d90 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> @@ -165,6 +165,8 @@ static int stmmac_mtl_setup(struct platform_device
> *pdev,
>>   	if (of_property_read_u32(rx_node, "snps,rx-queues-to-use",
>>   				 &plat->rx_queues_to_use))
>>   		plat->rx_queues_to_use = 1;
>> +	if (plat->rx_queues_to_use > MTL_MAX_RX_QUEUES)
>> +		plat->rx_queues_to_use = MTL_MAX_RX_QUEUES;
> 
> MTL_MAX_RX_QUEUES, MTL_MAX_TX_QUEUES and STMMAC_CH_MAX are defined to 8,
> this is correct for gmac4, but xgmac has 16 channels at most.

Yes, but these macros are used as the number of elements in some arrays.
(used in common.h and stmmac.h)

We can change these value to the maximum (16), though, the size of some
structures will increase so be careful.

> Drop these legacy defines and always use
> priv->dma_cap.number_rx_queues,
> priv->dma_cap.number_tx_queues,
> priv->dma_cap.number_tx_channel,
> priv->dma_cap.number_rx_channel,
> seems like a good option.

These values can be obtained in stmmac_dvr_probe() and this patch checks
the queue sizes before stmmac_dvr_probe(). I think we need to change the
way how to check them.

And when checking only with dma_cap values, the number of elements in 
the arrays might be exceeded.  It is necessary to take care of both the
arrays and the capabilities.

Thank you,

---
Best Regards
Kunihiko Hayashi