Re: [dpdk-dev] DPDK LPM table thread safety

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, May 21, 2015 at 05:51:34PM +0000, Shyam Sundar Govindaraj wrote:
> Hi
> 
>   I am interested in DPDK LPM implementation. I understand the high performance of this LPM table but, when it comes to multithreaded application, I read the following safety issue in DPDK documentation. I understand that multithread read and multithread write are not possible without locking table. But I want to know if single thread write and multithread read are possible with your implementation without any locking mechanism.

For the LPM library, I don't believe any such guarantees are made about that case.
However, assuming LPM for IPv4 here, the individual LPM entries are only 16-bits
in size, and, from what I see in the code, are always being assigned as a 
single entry, so the code may indeed by multi-reader, single-writer safe.
Unfortunately, it would need a proper examination of the code to fully verify this -
my quick re-reading of the code is not enough :-), and it may also depend, to some
extent on the compiler used, whether the compiler converts the assignment of one
16-bit structure to another 16-bit structure as a field-by-field copy, or as a
single copy of a uint16_t type.

Not a very satisfactory answer, I'm afraid, but if you do look at this further,
please let us know the result of your investigation. It would be good to get
the rte_lpm library made/confirmed thread-safe.

Regards,
/Bruce

> 
> 20. Thread Safety of DPDK Functions
> "The hash and LPM libraries are, by design, thread unsafe in order to maintain performance. However, if required the developer can add layers on top of these libraries to provide thread safety. Locking is not needed in all situations, and in both the hash and LPM libraries, lookups of values can be performed in parallel in multiple threads. Adding, removing or modifying values, however, cannot be done in multiple threads without using locking when a single hash or LPM table is accessed. Another alternative to locking would be to create multiple instances of these tables allowing each thread its own copy".
> http://dpdk.org/doc/guides/prog_guide/thread_safety_intel_dpdk_functions.html
> 
> Thanks
> Shyam