public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hao <haokexin@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next 2/4] net: macb: Consolidate MACB_CAPS_ISR_CLEAR_ON_WRITE checks in IRQ handler
Date: Wed, 1 Apr 2026 17:30:51 +0800	[thread overview]
Message-ID: <aczly5AD_PkYv6mJ@pek-khao-d3> (raw)
In-Reply-To: <20260331195400.16bb697c@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

> On Sat, 28 Mar 2026 18:17:46 +0800 Kevin Hao wrote:
On Tue, Mar 31, 2026 at 07:54:00PM -0700, Jakub Kicinski wrote:
> > Currently, the MACB_CAPS_ISR_CLEAR_ON_WRITE flag is checked in every
> > branch of the IRQ handler. This repeated evaluation is unnecessary.
> > By consolidating the flag check, we eliminate redundant loads of
> > bp->caps when TX and RX events occur simultaneously, a common scenario
> > under high network throughput. Additionally, this optimization reduces
> > the function size from 0x2e8 to 0x2c4.
> 
> feels a bit subjective TBH. An alternative improvement would be to
> factor out the conditional to a helper:
> 
> static void macb_queue_isr_clear(bp, queue, mask)
> {
> 	if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
> 		queue_writel(queue, ISR, mask);
> }

In addition to the similar pattern in the macb_interrupt() function, there are
seven other instances of this pattern in the macb driver.
  $ git grep "if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)" drivers/net/ethernet/cadence/ | wc -l
  7

I agree that using a helper function, as you proposed, would reduce the number
of source code lines and improve the readability of the driver. However, such
changes would not affect the final generated code.

The goal of my changes is to reduce both the footprint of macb_interrupt() and
the number of assembly instructions executed within its event loop.

Before the patch, the condition `if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)`
produced the following assembly:
  ffff800080d58b1c:       387b6a68        ldrb    w8, [x19, x27]
  ffff800080d58b20:       360000c8        tbz     w8, #0, ffff800080d58b38 <macb_interrupt+0xd0>

After the patch, the condition `if (isr_clear)` results in:
  ffff800080d58a4c:       360000d8        tbz     w24, #0, ffff800080d58a64 <macb_interrupt+0xac>

Thus, we eliminate two `ldrb` overheads per iteration of the event loop in
macb_interrupt() when both TX and RX events occur simultaneously. This also
reduces the function's footprint by 36 bytes, as the `ldrb` instructions are
omitted in each event branch.

Therefore, your proposed changes and mine serve different purposes.
I acknowledge that my change represents only a very slight optimization for
the interrupt handler. I am also open to your preference for improving source
code readability. Please let me know your decision.

Thanks,
Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2026-04-01  9:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-28 10:17 [PATCH net-next 0/4] net: macb: Remove dedicated IRQ handler for WoL Kevin Hao
2026-03-28 10:17 ` [PATCH net-next 1/4] net: macb: Replace open-coded implementation with napi_schedule() Kevin Hao
2026-03-28 10:17 ` [PATCH net-next 2/4] net: macb: Consolidate MACB_CAPS_ISR_CLEAR_ON_WRITE checks in IRQ handler Kevin Hao
2026-04-01  2:54   ` Jakub Kicinski
2026-04-01  9:30     ` Kevin Hao [this message]
2026-04-01 11:49       ` Nicolai Buchwitz
2026-04-02 13:44         ` Kevin Hao
2026-03-28 10:17 ` [PATCH net-next 3/4] net: macb: Factor out the handling of non-hot IRQ events into a separate function Kevin Hao
2026-04-01  2:54   ` Jakub Kicinski
2026-04-01  9:31     ` Kevin Hao
2026-03-28 10:17 ` [PATCH net-next 4/4] net: macb: Remove dedicated IRQ handler for WoL Kevin Hao
2026-04-01  2:55   ` Jakub Kicinski
2026-04-01  9:32     ` Kevin Hao
2026-04-03 16:17 ` [PATCH net-next 0/4] " Simon Horman

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=aczly5AD_PkYv6mJ@pek-khao-d3 \
    --to=haokexin@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=pabeni@redhat.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