From: "Théo Lebrun" <theo.lebrun@bootlin.com>
To: "Karumanchi, Vineeth" <vineeth@amd.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Nicolas Ferre" <nicolas.ferre@microchip.com>,
"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"Harini Katakam" <harini.katakam@xilinx.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Russell King" <linux@armlinux.org.uk>
Cc: <netdev@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Tawfik Bayouk" <tawfik.bayouk@mobileye.com>
Subject: Re: [PATCH net v5 3/5] net: macb: move ring size computation to functions
Date: Thu, 11 Sep 2025 11:14:52 +0200 [thread overview]
Message-ID: <DCPUUQHYSZGE.WH37VP8WHJ8E@bootlin.com> (raw)
In-Reply-To: <ba25cca0-adbf-435b-8c21-f03c567045b1@amd.com>
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
next prev parent reply other threads:[~2025-09-11 9:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 16:15 [PATCH net v5 0/5] net: macb: various fixes Théo Lebrun
2025-09-10 16:15 ` [PATCH net v5 1/5] dt-bindings: net: cdns,macb: allow tsu_clk without tx_clk Théo Lebrun
2025-09-10 16:15 ` [PATCH net v5 2/5] net: macb: remove illusion about TBQPH/RBQPH being per-queue Théo Lebrun
2025-09-10 16:15 ` [PATCH net v5 3/5] net: macb: move ring size computation to functions Théo Lebrun
2025-09-11 6:43 ` Karumanchi, Vineeth
2025-09-11 9:14 ` Théo Lebrun [this message]
2025-09-11 23:39 ` Jakub Kicinski
2025-09-10 16:15 ` [PATCH net v5 4/5] net: macb: single dma_alloc_coherent() for DMA descriptors Théo Lebrun
2025-09-10 16:15 ` [PATCH net v5 5/5] net: macb: avoid dealing with endianness in macb_set_hwaddr() Théo Lebrun
2025-09-11 3:13 ` Karumanchi, Vineeth
2025-09-11 9:22 ` Théo Lebrun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DCPUUQHYSZGE.WH37VP8WHJ8E@bootlin.com \
--to=theo.lebrun@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=geert@linux-m68k.org \
--cc=harini.katakam@xilinx.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=tawfik.bayouk@mobileye.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vineeth@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).