2016-02-22 02:07, Xie, Huawei: > On 2/19/2016 5:05 PM, Ilya Maximets wrote: > > On 19.02.2016 11:36, Xie, Huawei wrote: > >> On 2/19/2016 3:10 PM, Yuanhan Liu wrote: > >>> On Fri, Feb 19, 2016 at 09:32:43AM +0300, Ilya Maximets wrote: > >>>> Signed-off-by: Ilya Maximets <i.maximets at samsung.com> > >>>> --- > >>>> doc/guides/prog_guide/thread_safety_dpdk_functions.rst | 1 + > >>>> 1 file changed, 1 insertion(+) > >>>> > >>>> diff --git a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> index 403e5fc..13a6c89 100644 > >>>> --- a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> +++ b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst > >>>> The mempool library is based on the DPDK lockless ring library and > >>>> therefore is also multi-thread safe. > >>>> +rte_vhost_enqueue_burst() is also thread safe because based on lockless > >>>> ring-buffer algorithm like the ring library. > >>> FYI, Huawei meant to make rte_vhost_enqueue_burst() not be thread-safe, > >>> to aligh with the usage of rte_eth_tx_burst(). > >>> > >>> --yliu > >> I have a patch to remove the lockless enqueue. Unless there is strong > >> reason, i prefer vhost PMD to behave like other PMDs, with no internal > >> lockless algorithm. In future, for people who really need it, we could > >> have dynamic/static switch to enable it. > > Thomas, what is your opinion on this and my patch removing lockless enqueue?
The thread safety behaviour is part of the API specification. If we want to enable/disable such behaviour, it must be done with an API function. But it would introduce a conditional statement in the fast path. That's why the priority must be to keep a simple and consistent behaviour and try to build around. An API complexity may be considered only if there is a real (measured) gain.
