This diff looks good, except the re-check after kernel lock. It’s supposed `rt’ could became inconsistent, right? But what stops to make it inconsistent after first unlocked RTF_LLINFO flag check?
I think this re-check should gone. > On 21 May 2022, at 19:45, Hrvoje Popovski <[email protected]> wrote: > > On 18.5.2022. 20:52, Hrvoje Popovski wrote: >> On 18.5.2022. 17:31, Alexander Bluhm wrote: >>> Hi, >>> >>> For parallel IP forwarding I had put kernel lock around arpresolve() >>> as a quick workaround for crashes. Moving the kernel lock inside >>> the function makes the hot path lock free. I see slight prerformace >>> increase in my test and no lock contention in kstack flamegraph. >>> >>> http://bluhm.genua.de/perform/results/latest/2022-05-16T00%3A00%3A00Z/btrace/tcpbench_-S1000000_-t10_-n100_10.3.45.35-btrace-kstack.0.svg >>> http://bluhm.genua.de/perform/results/latest/patch-sys-arpresolve-kernel-lock.1/btrace/tcpbench_-S1000000_-t10_-n100_10.3.45.35-btrace-kstack.0.svg >>> >>> Search for kernel_lock. Matched goes from 0.6% to 0.2% >>> >>> We are running such a diff in our genua code for a while. I think >>> route flags need more love. I doubt that all flags and fields are >>> consistent when run on multiple CPU. But this diff does not make >>> it worse and increases MP pressure. >> >> Hi, >> >> I'm seeing increase of forwarding performance from 2Mpps to 2.4Mpps with >> this diff and NET_TASKQ=4 on 6 x E5-2643 v2 @ 3.50GHz, 3600.01 MHz >> >> Thank you .. >> >> > > Hi, > > I'm not seeing any fallout's with this diff. I'm running it on > production and test firewalls. >
