linux-kernel - Re: [PATCH net-next] net: ps3_gelic_net: Use napi_alloc_skb() and napi_gro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANn89i+q_KBrrhY-PjqdG9gxkdYyWy88Vbgu=PAr=SqDmvOyUw@mail.gmail.com>
Date: Mon, 1 Dec 2025 02:34:09 -0800
From: Eric Dumazet <edumazet@...gle.com>
To: Florian Fuchs <fuchsfl@...il.com>
Cc: Geoff Levand <geoff@...radead.org>, netdev@...r.kernel.org, 
	Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>, 
	"David S . Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, 
	Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, 
	Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <chleroy@...nel.org>, linuxppc-dev@...ts.ozlabs.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: ps3_gelic_net: Use napi_alloc_skb() and napi_gro_receive()

On Sun, Nov 30, 2025 at 11:51 AM Florian Fuchs <fuchsfl@...il.com> wrote:
>
> Use the napi functions napi_alloc_skb() and napi_gro_receive() instead
> of netdev_alloc_skb() and netif_receive_skb() for more efficient packet
> receiving. The switch to napi aware functions increases the RX
> throughput, reduces the occurrence of retransmissions and improves the
> resilience against SKB allocation failures.
>
> Signed-off-by: Florian Fuchs <fuchsfl@...il.com>
> ---
> Note: This change has been tested on real hardware Sony PS3 (CECHL04 PAL),
> the patch was tested for many hours, with continuous system load, high
> network transfer load and injected failslab errors.
>
> In my tests, the RX throughput increased up to 100% and reduced the
> occurrence of retransmissions drastically, with GRO enabled:
>
> iperf3 before and after the commit, where PS3 (with this driver) is on
> the receiving side:
> Before: [  5]   0.00-10.00  sec   551 MBytes   462 Mbits/sec receiver
> After:  [  5]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec receiver
>
> stats from the sending client to the PS3:
> Before: [  5]   0.00-10.00  sec   552 MBytes   463 Mbits/sec  3151 sender
> After:  [  5]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec   37  sender
>
>  drivers/net/ethernet/toshiba/ps3_gelic_net.c | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)

Patch looks fine to me. My PS3 died years ago, so I can not test it :)

Reviewed-by: Eric Dumazet <edumazet@...gle.com>

BTW, I think we can cleanup gelic_descr_prepare_rx() a bit :

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 5ee8e8980393c3491bf9cf91eb8e0dbb2df0f427..f4f34e9ed49c5b7fd1cf4ea3f5bfe7297e97ea23
100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -392,10 +392,8 @@ static int gelic_descr_prepare_rx(struct gelic_card *card,
        descr->hw_regs.payload.size = 0;

        descr->skb = netdev_alloc_skb(*card->netdev, rx_skb_size);
-       if (!descr->skb) {
-               descr->hw_regs.payload.dev_addr = 0; /* tell DMAC
don't touch memory */
+       if (!descr->skb)
                return -ENOMEM;
-       }

        offset = ((unsigned long)descr->skb->data) &
                (GELIC_NET_RXBUF_ALIGN - 1);
@@ -404,13 +402,12 @@ static int gelic_descr_prepare_rx(struct gelic_card *card,
        /* io-mmu-map the skb */
        cpu_addr = dma_map_single(ctodev(card), descr->skb->data,
                                  GELIC_NET_MAX_FRAME, DMA_FROM_DEVICE);
-       descr->hw_regs.payload.dev_addr = cpu_to_be32(cpu_addr);
+
        if (dma_mapping_error(ctodev(card), cpu_addr)) {
                dev_kfree_skb_any(descr->skb);
                descr->skb = NULL;
                dev_info(ctodev(card),
                         "%s:Could not iommu-map rx buffer\n", __func__);
-               gelic_descr_set_status(descr, GELIC_DESCR_DMA_NOT_IN_USE);
                return -ENOMEM;
        }