[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241213130212.1783302-1-edumazet@google.com>
Date: Fri, 13 Dec 2024 13:02:08 +0000
From: Eric Dumazet <edumazet@...gle.com>
To: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, Simon Horman <horms@...nel.org>,
David Ahern <dsahern@...nel.org>, Kuniyuki Iwashima <kuniyu@...zon.com>, eric.dumazet@...il.com,
Eric Dumazet <edumazet@...gle.com>
Subject: [PATCH net-next 0/4] inetpeer: reduce false sharing and atomic operations
After commit 8c2bd38b95f7 ("icmp: change the order of rate limits"),
there is a risk that a host receiving packets from an unique
source targeting closed ports is using a common inet_peer structure
from many cpus.
All these cpus have to acquire/release a refcount and update
the inet_peer timestamp (p->dtime)
Switch to pure RCU to avoid changing the refcount, and update
p->dtime only once per jiffy.
Tested:
DUT : 128 cores, 32 hw rx queues.
receiving 8,400,000 UDP packets per second, targeting closed ports.
Before the series:
- napi poll can not keep up, NIC drops 1,200,000 packets
per second.
- We use 20 % of cpu cycles
After this series:
- All packets are received (no more hw drops)
- We use 12 % of cpu cycles.
Eric Dumazet (4):
inetpeer: remove create argument of inet_getpeer_v[46]()
inetpeer: remove create argument of inet_getpeer()
inetpeer: update inetpeer timestamp in inet_getpeer()
inetpeer: do not get a refcount in inet_getpeer()
include/net/inetpeer.h | 12 +++++-------
net/ipv4/icmp.c | 6 +++---
net/ipv4/inetpeer.c | 29 ++++++++---------------------
net/ipv4/ip_fragment.c | 15 ++++++++++-----
net/ipv4/route.c | 17 +++++++++--------
net/ipv6/icmp.c | 6 +++---
net/ipv6/ip6_output.c | 6 +++---
net/ipv6/ndisc.c | 8 +++++---
8 files changed, 46 insertions(+), 53 deletions(-)
--
2.47.1.613.gc27f4b7a9f-goog
Powered by blists - more mailing lists