[PATCH net-next] net: ucc_geth: Batch RX packets before stack handoff

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

Speedup tested with bidirectional iperf3.

Before:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-10.00  sec   490 MBytes   411 Mbits/sec                  sender
[  5][TX-C]   0.00-10.01  sec   488 MBytes   409 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec   176 MBytes   147 Mbits/sec  167            sender
[  7][RX-C]   0.00-10.01  sec   175 MBytes   146 Mbits/sec                  receiver

After:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-10.00  sec   502 MBytes   421 Mbits/sec                  sender
[  5][TX-C]   0.00-10.01  sec   501 MBytes   420 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec   212 MBytes   178 Mbits/sec  148            sender
[  7][RX-C]   0.00-10.01  sec   211 MBytes   177 Mbits/sec                  receiver

Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <redacted>
---
 drivers/net/ethernet/freescale/ucc_geth.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 7af4b5e3f38e..bce1079fc06a 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c

@@ -2894,6 +2894,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
 	u32 bd_status;
 	u8 *bdBuffer;
 	struct net_device *dev;
+	LIST_HEAD(rx_list);
 
 	ugeth_vdbg("%s: IN", __func__);
 

@@ -2934,7 +2935,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
 
 			dev->stats.rx_bytes += length;
 			/* Send the packet up the stack */
-			netif_receive_skb(skb);
+			list_add_tail(&skb->list, &rx_list);
 		}
 
 		skb = get_new_skb(ugeth, bd);

@@ -2960,6 +2961,8 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
 		bd_status = in_be32((u32 __iomem *)bd);
 	}
 
+	netif_receive_skb_list(&rx_list);
+
 	ugeth->rxBd[rxQ] = bd;
 	return howmany;
 }

-- 
2.54.0

On Sun, May 17, 2026 at 12:28:56PM -0700, Rosen Penev wrote:

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

So my first through was, why is the core not doing this? The core NAPI
poll code can initialise the list. netif_receive_skb() withing the
driver poll would see there is a list and append to it. And when the
poll finished the NAPI core would pass the list up the stack? Maybe
this already exists and this driver is just using the wrong API?

	Andrew

On Sun, May 17, 2026 at 1:24 PM Andrew Lunn [off-list ref] wrote:

On Sun, May 17, 2026 at 12:28:56PM -0700, Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

So my first through was, why is the core not doing this? The core NAPI
poll code can initialise the list. netif_receive_skb() withing the
driver poll would see there is a list and append to it. And when the
poll finished the NAPI core would pass the list up the stack? Maybe
this already exists and this driver is just using the wrong API?

I do not know. I know several drivers are already using
netif_receive_skb_list, some even which support hardware checksumming.
See 0a25d92c6f4facaf2852f1aac4cebfe01dd57a91

The core seems to use netif_receive_skb_list_internal. I do not know
the details.

Anyway, the performance difference is real.

        Andrew

On Sun, May 17, 2026 at 01:44:40PM -0700, Rosen Penev wrote:

On Sun, May 17, 2026 at 1:24 PM Andrew Lunn [off-list ref] wrote:

quoted

On Sun, May 17, 2026 at 12:28:56PM -0700, Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

So my first through was, why is the core not doing this? The core NAPI
poll code can initialise the list. netif_receive_skb() withing the
driver poll would see there is a list and append to it. And when the
poll finished the NAPI core would pass the list up the stack? Maybe
this already exists and this driver is just using the wrong API?

I do not know. I know several drivers are already using
netif_receive_skb_list, some even which support hardware checksumming.
See 0a25d92c6f4facaf2852f1aac4cebfe01dd57a91

The core seems to use netif_receive_skb_list_internal. I do not know
the details.

Anyway, the performance difference is real.

I'm not disagreeing with that. But can a similar performance
difference be made for all drivers by doing this is the core?

That is the interesting question.

     Andrew

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

Speedup tested with bidirectional iperf3.

Please mention the platform / board as well.
-- 
pw-bot: cr

On Wed, May 20, 2026 at 4:57 PM Jakub Kicinski [off-list ref] wrote:

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

GRO will result in slower routing performance because there is no
hardware checksum.

quoted

Speedup tested with bidirectional iperf3.

Please mention the platform / board as well.

Will do.

--
pw-bot: cr

On Wed, 20 May 2026 17:39:41 -0700 Rosen Penev wrote:

quoted

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:  

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.  

GRO should be even better.  

GRO will result in slower routing performance because there is no
hardware checksum.

Mention this in the commit message too.
Network adapters without checksum offload are pretty rare these days.
Speaking of being old, do you know if this driver is used in practice?
Maybe we can delete it.

On Wed, May 20, 2026 at 5:45 PM Jakub Kicinski [off-list ref] wrote:

On Wed, 20 May 2026 17:39:41 -0700 Rosen Penev wrote:

quoted

quoted

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

GRO will result in slower routing performance because there is no
hardware checksum.

Mention this in the commit message too.

Will do.

Network adapters without checksum offload are pretty rare these days.

Qualcomm continues to make adapters like these.

Speaking of being old, do you know if this driver is used in practice?

Yes. In OpenWrt with kernel 6.18.

Maybe we can delete it.

Way too early. I've tried previously to clean it up some but got rejected.

Hi Jakub,

Le 21/05/2026 à 02:45, Jakub Kicinski a écrit :

On Wed, 20 May 2026 17:39:41 -0700 Rosen Penev wrote:

quoted

quoted

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

GRO will result in slower routing performance because there is no
hardware checksum.

Mention this in the commit message too.
Network adapters without checksum offload are pretty rare these days.
Speaking of being old, do you know if this driver is used in practice?
Maybe we can delete it.

That's way too early to remove that driver.

UCC is what provides Ethernet connectivity in the powerpc MPC83xx CPU 
family. This family has just been declared End Of Life by January this 
year with a Last Time Buy Date 30 Jul 2026 and Last Time Delivery Date 
by 30 Apr 2027. We have that CPU on hundreds of boards spread all over 
Europe and have to maintain those systems for the next 10 to 15 years if 
not even more.

So we can maybe reconsider removing that driver by 2040 but unlikely before.

Christophe

On Wed, May 20, 2026 at 5:39 PM Rosen Penev [off-list ref] wrote:

On Wed, May 20, 2026 at 4:57 PM Jakub Kicinski [off-list ref] wrote:

quoted

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

GRO will result in slower routing performance because there is no
hardware checksum.

Then provide a knob or something, instead of trying to avoid GRO.

For end hosts (forwarding not enabled), checksum will need to be
computed anyway.
GRO should be faster for them.

Note that GRO also uses netif_receive_skb_list_internal()

On Thu, May 21, 2026 at 6:41 AM Eric Dumazet [off-list ref] wrote:

On Wed, May 20, 2026 at 5:39 PM Rosen Penev [off-list ref] wrote:

quoted

On Wed, May 20, 2026 at 4:57 PM Jakub Kicinski [off-list ref] wrote:

quoted

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

GRO will result in slower routing performance because there is no
hardware checksum.

Then provide a knob or something, instead of trying to avoid GRO.

For end hosts (forwarding not enabled), checksum will need to be
computed anyway.
GRO should be faster for them.

Note that GRO also uses netif_receive_skb_list_internal()

so you recommend switching to napi_gro_receive even though there's no
RX hardware checksum?

On Thu, May 21, 2026 at 4:29 PM Rosen Penev [off-list ref] wrote:

On Thu, May 21, 2026 at 6:41 AM Eric Dumazet [off-list ref] wrote:

quoted

On Wed, May 20, 2026 at 5:39 PM Rosen Penev [off-list ref] wrote:

quoted

On Wed, May 20, 2026 at 4:57 PM Jakub Kicinski [off-list ref] wrote:

quoted

On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:

quoted

Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.

GRO should be even better.

GRO will result in slower routing performance because there is no
hardware checksum.

Then provide a knob or something, instead of trying to avoid GRO.

For end hosts (forwarding not enabled), checksum will need to be
computed anyway.
GRO should be faster for them.

Note that GRO also uses netif_receive_skb_list_internal()

so you recommend switching to napi_gro_receive even though there's no
RX hardware checksum?

Certainly.

There is a reason we added support for sw checksum in GRO years ago.

Most linux hosts on this planet do not forward packets.
And if they do, there is a big chance the egress device supports TSO
or tx checksum offload.