netdev - Re: [PATCH net v5 3/5] net: macb: move ring size computation to functions

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DCPUUQHYSZGE.WH37VP8WHJ8E@bootlin.com>
Date: Thu, 11 Sep 2025 11:14:52 +0200
From: Théo Lebrun <theo.lebrun@...tlin.com>
To: "Karumanchi, Vineeth" <vineeth@....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>, "Rob Herring" <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 "Nicolas Ferre" <nicolas.ferre@...rochip.com>, "Claudiu Beznea"
 <claudiu.beznea@...on.dev>, "Geert Uytterhoeven" <geert@...ux-m68k.org>,
 "Harini Katakam" <harini.katakam@...inx.com>, "Richard Cochran"
 <richardcochran@...il.com>, "Russell King" <linux@...linux.org.uk>
Cc: <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>, "Tawfik Bayouk"
 <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH net v5 3/5] net: macb: move ring size computation to
 functions

Hello Vineeth,

On Thu Sep 11, 2025 at 8:43 AM CEST, Karumanchi, Vineeth wrote:
> On 9/10/2025 9:45 PM, Théo Lebrun wrote:
>>   #define DEFAULT_TX_RING_SIZE	512 /* must be power of 2 */
>>   #define MIN_TX_RING_SIZE	64
>>   #define MAX_TX_RING_SIZE	4096
>> -#define TX_RING_BYTES(bp) (macb_dma_desc_get_size(bp) \
>> - * (bp)->tx_ring_size)
>>   
>>   /* level of occupied TX descriptors under which we wake up TX process */
>>   #define MACB_TX_WAKEUP_THRESH(bp)	(3 * (bp)->tx_ring_size / 4)
>> @@ -2470,11 +2466,20 @@ static void macb_free_rx_buffers(struct macb *bp)
>>   	}
>>   }
>>   
>> +static unsigned int macb_tx_ring_size_per_queue(struct macb *bp)
>> +{
>> + return macb_dma_desc_get_size(bp) * bp->tx_ring_size + bp- 
>>  >tx_bd_rd_prefetch;
>> +}
>> +
>> +static unsigned int macb_rx_ring_size_per_queue(struct macb *bp)
>> +{
>> + return macb_dma_desc_get_size(bp) * bp->rx_ring_size + bp- 
>>  >rx_bd_rd_prefetch;
>> +}
>> +
>
> it would be good to have these functions as inline.
> May be as a separate patch.

I don't see why? Compilers are clever pieces, they'll know to inline it.

If we added inline to macb_{tx,rx}_ring_size_per_queue(), should we also
add it to macb_dma_desc_get_size()? I do not know, but my compiler
decided to inline it as well. It might make other decisions on other
platforms.

Last point I see: those two functions are not called in the hotpath,
only at alloc & free. If we talk about inline for the theoretical speed
gain, then it doesn't matter in that case. If it is a code size aspect,
then once again the compiler is more aware than myself.

I don't like the tone, but it is part of the kernel doc and is on topic:
https://www.kernel.org/doc/html/latest/process/coding-style.html#the-inline-disease

Thanks Vineeth!

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com