[PATCH net 0/2] r8169: fix checksum eligibility and failed TX batch progress

[PATCH net 0/2] r8169: fix checksum eligibility and failed TX batch progress

[iugfdin]

This series fixes two TX-path issues found while investigating a report
of loss with an RTL8125D 2.5GbE controller (PCI revision 0c, XID 688).

The first patch preserves hardware checksum eligibility when a packet is
already at least as long as the padding target. The second ensures that
a failed skb does not leave previously committed xmit_more packets
without a transmit poll request.

Neither patch is claimed to resolve the reported physical packet loss.
The reporter observed 10-20% loss, particularly at 2.5 Gb/s, while a
vendor Realtek driver/firmware combination worked. No affected NIC was
available in the development environment. The reporter identified the
loaded firmware as rtl8125d-1_0.0.7 10/15/24. A possible firmware-related
cause of the reported loss remains under separate investigation.

The series is based on net commit:
6dc989ea46b96ce170840174b4a38c4a387fb005

Verification:
- The patched r8169 objects build with Clang 23.1.1, W=1, under x86-64
  allmodconfig and allyesconfig on that net tree. These are driver-target
  builds, not full-kernel builds or boot tests.
- A userspace harness extracts the production functions at run time,
  with modeled kernel/DMA/MMIO boundaries and ASan/UBSan. The checksum
  matrix changes from 42 failed assertions out of 85 to zero; the TX
  matrix changes from 40 failed assertions out of 102 to zero.
- The matrices cover normal IPv4/IPv6 TCP/UDP, short and PTP padding,
  transport offsets, GSO, ring wrap, successful fragments, failed
  head/fragment DMA mapping, allocation failures and queue accounting.
- Both patches pass strict checkpatch and apply cleanly to the net base.

AI assistance was used to inspect the driver, compare upstream/vendor
behavior, develop the fixes and source-executing harness, and draft this
submission. The investigation started from the packet-loss report; it
did not establish either issue as the cause on the reported hardware.
The patches carry Assisted-by: LLM.

Patch 1 fixes 8d520b4de3ed ("r8169: work around RTL8125 UDP hw bug").
Patch 2 fixes ef14358546b1 ("r8169: make use of xmit_more").

The two changes are independent, and the complete series changes only
drivers/net/ethernet/realtek/r8169_main.c.

base-commit: 6dc989ea46b96ce170840174b4a38c4a387fb005

[PATCH net 1/2] r8169: preserve checksum offload when packet padding is unnecessary

[iugfdin]

rtl_quirk_packet_padto() returns the minimum packet length required by
the padding quirks. For RTL8168evl and RTL8125-family chips this is at
least ETH_ZLEN, even when the skb is already longer.

rtl8169_features_check() treats that nonzero target as a boolean and
therefore disables checksum offload for ordinary non-GSO
CHECKSUM_PARTIAL packets on these chips. Packets that need no padding
are unnecessarily checksummed in software.

Compare the skb length with the padding target instead. Packets that
actually need padding continue to use software checksumming; the
existing short-frame and transport-offset checks are unchanged.

Fixes: 8d520b4de3ed ("r8169: work around RTL8125 UDP hw bug")
Assisted-by: LLM
Signed-off-by: iugfdin <iugfdin@proton.me>
---
Tested with W=1 driver-target builds on net under x86-64
allmodconfig and allyesconfig, and source-executing ASan/UBSan
checks with modeled kernel/DMA/MMIO boundaries. No physical
Realtek NIC was available; this is not an on-device test claim.

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index ee1bc9bd..045fcd4d 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4677,7 +4677,7 @@ static netdev_features_t rtl8169_features_check(struct sk_buff *skb,
 		if (skb->len < ETH_ZLEN)
 			features &= ~NETIF_F_CSUM_MASK;
 
-		if (rtl_quirk_packet_padto(tp, skb))
+		if (skb->len < rtl_quirk_packet_padto(tp, skb))
 			features &= ~NETIF_F_CSUM_MASK;
 
 		if (skb_transport_offset(skb) > TCPHO_MAX &&

Re: [PATCH net 1/2] r8169: preserve checksum offload when packet padding is unnecessary

[Simon Horman]

On Sat, Oct 03, 2026 at 12:07:54AM +0000, iugfdin wrote:
> rtl_quirk_packet_padto() returns the minimum packet length required by
> the padding quirks. For RTL8168evl and RTL8125-family chips this is at
> least ETH_ZLEN, even when the skb is already longer.
> 
> rtl8169_features_check() treats that nonzero target as a boolean and
> therefore disables checksum offload for ordinary non-GSO
> CHECKSUM_PARTIAL packets on these chips. Packets that need no padding
> are unnecessarily checksummed in software.
> 
> Compare the skb length with the padding target instead. Packets that
> actually need padding continue to use software checksumming; the
> existing short-frame and transport-offset checks are unchanged.
> 
> Fixes: 8d520b4de3ed ("r8169: work around RTL8125 UDP hw bug")
> Assisted-by: LLM
> Signed-off-by: iugfdin <iugfdin@proton.me>

Please consider using your real name in the From header and Signed-off-by tag.
Apologies if I am misreading things and that is already the case.

> ---
> Tested with W=1 driver-target builds on net under x86-64
> allmodconfig and allyesconfig, and source-executing ASan/UBSan
> checks with modeled kernel/DMA/MMIO boundaries. No physical
> Realtek NIC was available; this is not an on-device test claim.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net 1/2] r8169: preserve checksum offload when packet padding is unnecessary

[Jakub Kicinski]

On Wed, 7 Oct 2026 16:34:38 +0100 Simon Horman wrote:
> > Signed-off-by: iugfdin <iugfdin@proton.me>  
> 
> Please consider using your real name in the From header and Signed-off-by tag.
> Apologies if I am misreading things and that is already the case.

Legal name is indeed required. If that's too much to ask - we can
certainly live without this contribution.
-- 
pw-bot: cr

[PATCH net 2/2] r8169: flush pending transmit packets when an skb is dropped

[iugfdin]

rtl8169_start_xmit() can defer a transmit poll when xmit_more is set.
If a later skb fails preparation or DMA mapping, the shared error
path drops it without issuing that deferred poll. If the failed skb
ends the batch, previously committed packets can remain pending
until another packet or recovery path kicks the device.

Issue a transmit poll after cleaning up the failed skb so earlier
packets can make progress. The failed skb still does not advance
the producer index or contribute to BQL accounting.

Fixes: ef14358546b1 ("r8169: make use of xmit_more")
Assisted-by: LLM
Signed-off-by: iugfdin <iugfdin@proton.me>
---
Tested with W=1 driver-target builds on net under x86-64
allmodconfig and allyesconfig, and source-executing ASan/UBSan
checks with modeled kernel/DMA/MMIO boundaries. No physical
Realtek NIC was available; this is not an on-device test claim.

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 045fcd4d..ae8ea0d8 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4625,6 +4625,8 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
 err_dma_0:
 	dev_kfree_skb_any(skb);
 	dev->stats.tx_dropped++;
+	/* Flush packets queued with xmit_more before this failure. */
+	rtl8169_doorbell(tp);
 	return NETDEV_TX_OK;
 }
 

Re: [PATCH net 2/2] r8169: flush pending transmit packets when an skb is dropped

[Simon Horman]

On Sat, Oct 03, 2026 at 12:08:01AM +0000, iugfdin wrote:
> rtl8169_start_xmit() can defer a transmit poll when xmit_more is set.
> If a later skb fails preparation or DMA mapping, the shared error
> path drops it without issuing that deferred poll. If the failed skb
> ends the batch, previously committed packets can remain pending
> until another packet or recovery path kicks the device.
> 
> Issue a transmit poll after cleaning up the failed skb so earlier
> packets can make progress. The failed skb still does not advance
> the producer index or contribute to BQL accounting.
> 
> Fixes: ef14358546b1 ("r8169: make use of xmit_more")
> Assisted-by: LLM
> Signed-off-by: iugfdin <iugfdin@proton.me>
> ---
> Tested with W=1 driver-target builds on net under x86-64
> allmodconfig and allyesconfig, and source-executing ASan/UBSan
> checks with modeled kernel/DMA/MMIO boundaries. No physical
> Realtek NIC was available; this is not an on-device test claim.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net 0/2] r8169: fix checksum eligibility and failed TX batch progress

[Geert Uytterhoeven]

	Hi iugfdin,

Thanks for your series!

> This series fixes two TX-path issues found while investigating a report
> of loss with an RTL8125D 2.5GbE controller (PCI revision 0c, XID 688).

Do you have a link to that report?

> The first patch preserves hardware checksum eligibility when a packet is
> already at least as long as the padding target. The second ensures that
> a failed skb does not leave previously committed xmit_more packets
> without a transmit poll request.
>
> Neither patch is claimed to resolve the reported physical packet loss.
> The reporter observed 10-20% loss, particularly at 2.5 Gb/s, while a
> vendor Realtek driver/firmware combination worked. No affected NIC was
> available in the development environment. The reporter identified the
> loaded firmware as rtl8125d-1_0.0.7 10/15/24. A possible firmware-related
> cause of the reported loss remains under separate investigation.

I haven't tested your series, but without it, I see 40% packet loss at
2.5Gbps on the same controller revision, when rtl8125d-1.fw from
linux-firmware is loaded[1].  Forcing a lower speed of 1 Gbps work fine.

With that firmware file moved out of the way, i.e. using the built-in
firmware, 2.5 Gbps works fine for me, too...

[1] "RTL8125D breaks at 2.5Gbps"
    https://lore.kernel.org/CAMuHMdXPAeHoeaQbM9rXbXukoMbFV+0k28n6sRMw8XF8720WUA@mail.gmail.com/

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds