[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAVpQUA2ejs5QUHnL54uZO+BhiVn0yfp3A3aLyuJw79Udb_3ug@mail.gmail.com>
Date: Tue, 26 Aug 2025 22:32:17 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
eric.dumazet@...il.com, Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH v2 net-next 4/5] udp: add drop_counters to udp socket
On Tue, Aug 26, 2025 at 5:50 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> When a packet flood hits one or more UDP sockets, many cpus
> have to update sk->sk_drops.
>
> This slows down other cpus, because currently
> sk_drops is in sock_write_rx group.
>
> Add a socket_drop_counters structure to udp sockets.
>
> Using dedicated cache lines to hold drop counters
> makes sure that consumers no longer suffer from
> false sharing if/when producers only change sk->sk_drops.
>
> This adds 128 bytes per UDP socket.
>
> Tested with the following stress test, sending about 11 Mpps
> to a dual socket AMD EPYC 7B13 64-Core.
>
> super_netperf 20 -t UDP_STREAM -H DUT -l10 -- -n -P,1000 -m 120
> Note: due to socket lookup, only one UDP socket is receiving
> packets on DUT.
>
> Then measure receiver (DUT) behavior. We can see both
> consumer and BH handlers can process more packets per second.
>
> Before:
>
> nstat -n ; sleep 1 ; nstat | grep Udp
> Udp6InDatagrams 615091 0.0
> Udp6InErrors 3904277 0.0
> Udp6RcvbufErrors 3904277 0.0
>
> After:
>
> nstat -n ; sleep 1 ; nstat | grep Udp
> Udp6InDatagrams 816281 0.0
> Udp6InErrors 7497093 0.0
> Udp6RcvbufErrors 7497093 0.0
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@...gle.com>
Powered by blists - more mailing lists