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.

Reply via email to