From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
Andrew Lunn <andrew@lunn.ch>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org,
Paolo Abeni <pabeni@redhat.com>, Sam Edwards <cfsworks@gmail.com>
Subject: Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
Date: Sun, 12 Apr 2026 16:01:59 +0200 [thread overview]
Message-ID: <266998d8-7e38-4bae-a4df-2f889538fe88@bootlin.com> (raw)
In-Reply-To: <E1wBBaR-0000000GZHR-1dbM@rmk-PC.armlinux.org.uk>
Hi Russell,
On 10/04/2026 15:07, Russell King (Oracle) wrote:
> Enable receive process stopped and receive buffer unavailable
> interrupts, so that the statistic counters can be updated.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> Since we are seeing receive buffer exhaustion on several platforms,
> let's enable the interrupts so the statistics we publish via ethtool -S
> actually work to aid diagnosis. I've been in two minds about whether
> to send this patch, but given the problems with stmmac at the moment,
> I think it should be merged.
Looks like my reply to your original RFC was lost in limbo as the review/test tags are missing.
Here's my original answer :
It works, I can indeed see the stats get properly updated on imx8mp 🙂
There's one downside to it though, which is that as soon as we hit a situation
where we don't have RX bufs available, this patchs has a tendancy to make things
worse as we'll trigger interrupts for each packet we receive and that we can't
process, making it even longer for queues to be refilled.
It shows on iperf3 with small packets :
---- Before patch, 17% packet loss on UDP 56 bytes packets -----------------
# iperf3 -u -b 0 -l 56 -c 192.168.2.1 -R
Connecting to host 192.168.2.1, port 5201
Reverse mode, remote host 192.168.2.1 is sending
[ 5] local 192.168.2.18 port 47851 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 10.7 MBytes 90.0 Mbits/sec 0.003 ms 48550/249650 (19%)
[ 5] 1.00-2.00 sec 11.3 MBytes 95.0 Mbits/sec 0.003 ms 41881/253832 (16%)
[ 5] 2.00-3.00 sec 11.3 MBytes 94.9 Mbits/sec 0.002 ms 42060/253913 (17%)
[ 5] 3.00-4.00 sec 11.3 MBytes 95.1 Mbits/sec 0.003 ms 41499/253785 (16%)
[ 5] 4.00-5.00 sec 11.3 MBytes 94.6 Mbits/sec 0.003 ms 42663/253787 (17%)
[ 5] 5.00-6.00 sec 11.3 MBytes 94.9 Mbits/sec 0.006 ms 41976/253719 (17%)
[ 5] 6.00-7.00 sec 11.3 MBytes 94.5 Mbits/sec 0.003 ms 43133/253999 (17%)
[ 5] 7.00-8.00 sec 11.3 MBytes 95.0 Mbits/sec 0.004 ms 41442/253579 (16%)
[ 5] 8.00-9.00 sec 11.4 MBytes 95.2 Mbits/sec 0.004 ms 41518/254131 (16%)
[ 5] 9.00-10.00 sec 11.2 MBytes 94.3 Mbits/sec 0.006 ms 43580/254143 (17%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 135 MBytes 114 Mbits/sec 0.000 ms 0/0 (0%) sender
[ 5] 0.00-10.00 sec 112 MBytes 94.3 Mbits/sec 0.006 ms 428302/2534538 (17%) receiver
iperf Done.
# ethtool -S eth1 | grep rx_buf_unav_irq
rx_buf_unav_irq: 0
---- After patch, 22% packet loss on UDP 56 bytes packets ----------------------
# iperf3 -u -b 0 -l 56 -c 192.168.2.1 -R
Connecting to host 192.168.2.1, port 5201
Reverse mode, remote host 192.168.2.1 is sending
[ 5] local 192.168.2.18 port 42121 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 10.3 MBytes 85.8 Mbits/sec 0.004 ms 55146/247172 (22%)
[ 5] 1.00-2.00 sec 10.6 MBytes 89.1 Mbits/sec 0.003 ms 54699/253355 (22%)
[ 5] 2.00-3.00 sec 10.6 MBytes 89.0 Mbits/sec 0.003 ms 55231/253887 (22%)
[ 5] 3.00-4.00 sec 10.6 MBytes 88.9 Mbits/sec 0.003 ms 55138/253602 (22%)
[ 5] 4.00-5.00 sec 10.6 MBytes 89.0 Mbits/sec 0.003 ms 54938/253722 (22%)
[ 5] 5.00-6.00 sec 10.6 MBytes 88.9 Mbits/sec 0.003 ms 55273/253580 (22%)
[ 5] 6.00-7.00 sec 10.6 MBytes 89.0 Mbits/sec 0.003 ms 55202/253986 (22%)
[ 5] 7.00-8.00 sec 10.6 MBytes 89.1 Mbits/sec 0.003 ms 55047/253958 (22%)
[ 5] 8.00-9.00 sec 10.6 MBytes 88.9 Mbits/sec 0.003 ms 55612/254140 (22%)
[ 5] 9.00-10.00 sec 10.6 MBytes 89.0 Mbits/sec 0.003 ms 55683/254403 (22%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 135 MBytes 113 Mbits/sec 0.000 ms 0/0 (0%) sender
[ 5] 0.00-10.00 sec 106 MBytes 88.7 Mbits/sec 0.003 ms 551969/2531805 (22%) receiver
iperf Done.
# ethtool -S eth1 | grep rx_buf_unav_irq
rx_buf_unav_irq: 30624
So clearly there are pros and cons with this, but I don't want to fall into the
"let's not break microbenchmarks" pitfall.
I personnaly find the stat useful, and that having the stat visible to user
but stuck at 0 is misleading so,
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
>
> drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
> index af6580332d49..43b036d4e95b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
> @@ -99,6 +99,8 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
> #define DMA_CHAN_INTR_ENA_NIE_4_10 BIT(15)
> #define DMA_CHAN_INTR_ENA_AIE_4_10 BIT(14)
> #define DMA_CHAN_INTR_ENA_FBE BIT(12)
> +#define DMA_CHAN_INTR_ENA_RPS BIT(8)
> +#define DMA_CHAN_INTR_ENA_RBU BIT(7)
> #define DMA_CHAN_INTR_ENA_RIE BIT(6)
> #define DMA_CHAN_INTR_ENA_TIE BIT(0)
>
> @@ -107,6 +109,8 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
> DMA_CHAN_INTR_ENA_TIE)
>
> #define DMA_CHAN_INTR_ABNORMAL (DMA_CHAN_INTR_ENA_AIE | \
> + DMA_CHAN_INTR_ENA_RPS | \
> + DMA_CHAN_INTR_ENA_RBU | \
> DMA_CHAN_INTR_ENA_FBE)
> /* DMA default interrupt mask for 4.00 */
> #define DMA_CHAN_INTR_DEFAULT_MASK (DMA_CHAN_INTR_NORMAL | \
> @@ -117,6 +121,8 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
> DMA_CHAN_INTR_ENA_TIE)
>
> #define DMA_CHAN_INTR_ABNORMAL_4_10 (DMA_CHAN_INTR_ENA_AIE_4_10 | \
> + DMA_CHAN_INTR_ENA_RPS | \
> + DMA_CHAN_INTR_ENA_RBU | \
> DMA_CHAN_INTR_ENA_FBE)
> /* DMA default interrupt mask for 4.10a */
> #define DMA_CHAN_INTR_DEFAULT_MASK_4_10 (DMA_CHAN_INTR_NORMAL_4_10 | \
next prev parent reply other threads:[~2026-04-12 14:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 13:07 [PATCH net-next] net: stmmac: enable RPS and RBU interrupts Russell King (Oracle)
2026-04-12 14:01 ` Maxime Chevallier [this message]
2026-04-12 14:23 ` Russell King (Oracle)
2026-04-13 1:42 ` Sam Edwards
2026-04-13 7:24 ` Russell King (Oracle)
2026-04-13 7:28 ` Russell King (Oracle)
2026-04-13 18:02 ` Jakub Kicinski
2026-04-13 18:49 ` Russell King (Oracle)
2026-04-13 20:50 ` Jakub Kicinski
2026-04-13 20:53 ` Russell King (Oracle)
2026-04-13 21:54 ` Sam Edwards
2026-04-14 14:13 ` Russell King (Oracle)
2026-04-15 1:19 ` Russell King (Oracle)
2026-04-15 2:12 ` Sam Edwards
2026-04-15 12:43 ` Russell King (Oracle)
2026-04-15 17:38 ` Sam Edwards
2026-04-15 19:37 ` Russell King (Oracle)
2026-04-15 20:50 ` Sam Edwards
2026-04-16 0:02 ` Russell King (Oracle)
2026-04-13 22:00 ` patchwork-bot+netdevbpf
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=266998d8-7e38-4bae-a4df-2f889538fe88@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=cfsworks@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rmk+kernel@armlinux.org.uk \
/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