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
