Thread (5 messages) 5 messages, 3 authors, 2024-09-25

Re: [PATCH v3] net/bridge: Optimizing read-write locks in ebtables.c

From: Stephen Hemminger <stephen@networkplumber.org>
Date: 2024-09-24 16:40:57
Also in: bridge, lkml, netfilter-devel

On Tue, 24 Sep 2024 15:46:17 +0200
Eric Dumazet [off-list ref] wrote:
On Tue, Sep 24, 2024 at 3:33 PM Stephen Hemminger
[off-list ref] wrote:
quoted
On Tue, 24 Sep 2024 17:09:06 +0800
yushengjin [off-list ref] wrote:
 
quoted
When conducting WRK testing, the CPU usage rate of the testing machine was
100%. forwarding through a bridge, if the network load is too high, it may
cause abnormal load on the ebt_do_table of the kernel ebtable module, leading
to excessive soft interrupts and sometimes even directly causing CPU soft
deadlocks.

After analysis, it was found that the code of ebtables had not been optimized
for a long time, and the read-write locks inside still existed. However, other
arp/ip/ip6 tables had already been optimized a lot, and performance bottlenecks
in read-write locks had been discovered a long time ago.

Ref link: https://lore.kernel.org/lkml/20090428092411.5331c4a1@nehalam/ (local)

So I referred to arp/ip/ip6 modification methods to optimize the read-write
lock in ebtables.c.  
What about doing RCU instead, faster and safer.  
Safer ? How so ?

Stephen, we have used this stuff already in other netfilter components
since 2011

No performance issue at all.
I was thinking that lockdep and analysis tools do better job looking at RCU.
Most likely, the number of users of ebtables was small enough that nobody looked
hard at it until now.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help