<snip> > > > > On Fri, 6 Sep 2019 18:26:13 +0800 > > Ruifeng Wang <ruifeng.w...@arm.com> wrote: > > > > > Lock-free mode is supported by hash library and LPM library. > > > Now we add an option for l3fwd example to enable the lock-free mode. > > > Necessary preparation steps are added to use lock-free LPM mode. > > > > If lock-free mode works it should just do that. > > Having options mean that there are two test cases; which inevitably > > leads to one of them being broken. > > Agree that having options will add scenarios that being tested. > Since these different scenarios are supported by Hash / LPM library, the tests > on them should be valid. > As l3fwd application is always used to benchmark data path performance, > make both supported modes available can help user to easily collect data and > compare. > In the long run, we can make lock-free mode the default used by l3fwd when > it is fine tuned. I agree that if lock-free works we should just do that. It makes L3fwd application more practical.
The LPM has always been lock free on the data plane side. The writer side parts and quiescent state reporting on the data plane are being added now. With the optimizations in the last release, the lock free hash algorithm's performance has come very close to RW lock based algorithm both for hit and miss cases for single core. Unfortunately (😊), any further optimizations seem to increase the performance of the RW lock based algorithm as well. So, looks like there will be that small difference between the 2 algorithms. However, a practical application will use other cores in the SoC and lock-free algorithms scale better with increasing number of cores. IMO, we should bite the bullet and make hash lock-free algorithm default.
