On Thu, May 21, 2026 at 4:29 PM Rosen Penev <[email protected]> wrote: > > On Thu, May 21, 2026 at 6:41 AM Eric Dumazet <[email protected]> wrote: > > > > On Wed, May 20, 2026 at 5:39 PM Rosen Penev <[email protected]> wrote: > > > > > > On Wed, May 20, 2026 at 4:57 PM Jakub Kicinski <[email protected]> wrote: > > > > > > > > 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. > > > 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.
