Re: [dpdk-dev] [PATCH RFC 4/4] doc: add note about rte_vhost_enqueue_burst thread safety.

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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@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.