From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id 54B6C2BA1 for ; Wed, 24 Feb 2016 06:06:49 +0100 (CET) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O31006R9CVB1D00@mailout1.w1.samsung.com> for dev@dpdk.org; Wed, 24 Feb 2016 05:06:47 +0000 (GMT) X-AuditID: cbfec7f5-f79b16d000005389-4f-56cd3a678570 Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 2B.CF.21385.76A3DC65; Wed, 24 Feb 2016 05:06:47 +0000 (GMT) Received: from [106.109.129.180] by eusync3.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O31000JBCVAQO80@eusync3.samsung.com>; Wed, 24 Feb 2016 05:06:47 +0000 (GMT) To: "Xie, Huawei" , Thomas Monjalon References: <1455863563-15751-1-git-send-email-i.maximets@samsung.com> <56C6DACA.7040109@samsung.com> <3343596.CjhAKlsm75@xps13> From: Ilya Maximets Message-id: <56CD3A66.5020804@samsung.com> Date: Wed, 24 Feb 2016 08:06:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsVy+t/xq7rpVmfDDA70yVu8+7SdyaJ95lkm i4mTTCymP42wONbzidVi8mwpiy+bprNZXJ9wgdWBw+Ni/x1Gjw0n+lk9fi1YyurR+FzCY/Ge l0wed67tYfOYdzLQo2/LKsYAjigum5TUnMyy1CJ9uwSujMUb0wsmiFdM/vaUsYFxlnAXIyeH hICJxPJ5K9ggbDGJC/fWA9lcHEICSxklts3+zwjhvGCUeLDkHjtIlbBApERD83kwW0QgXGLi zIVMEEUzmCR+nH3BCuIwC7xjlDh9eA1YFZuAjsSp1UcYQWxeAS2Jx59WgNksAqoSFybcYAKx RQUiJA53drFD1AhK/Jh8jwXE5hQIk3i2ch1zFyMH0FA9ifsXtUDCzALyEpvXvGWewCgwC0nH LISqWUiqFjAyr2IUTS1NLihOSs810itOzC0uzUvXS87P3cQIiYKvOxiXHrM6xCjAwajEw/tg w5kwIdbEsuLK3EOMEhzMSiK8mdxnw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzztz1PkRIID2x JDU7NbUgtQgmy8TBKdXAaPxwRVXvPXX3y+uZbm+M/f19UeLe4w31WttrF887f0P9dpT+MVuN OW9rv08+7JC0Icjs7N3Zdgz/BJJOBHTnXdifMrWSZ4FDF/cM7cU9Ho90+0uqZ/SkNMd/sW/t Di00iWrzVz7kH3p43/Leicd/bzAx8z31RO7k/hPlXzZkzo6bUJe0qGWdtBJLcUaioRZzUXEi ACRzegh+AgAA Cc: Dyasly Sergey , "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH RFC 4/4] doc: add note about rte_vhost_enqueue_burst thread safety. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 05:06:49 -0000 On 23.02.2016 08:56, Xie, Huawei wrote: > On 2/22/2016 6:16 PM, Thomas Monjalon wrote: >> 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 >>>>>>> --- >>>>>>> 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. > > Let us put the gain aside temporarily. I would do the measurement. > Vhost is wrapped as a PMD in Tetsuya's patch. And also in DPDK OVS's > case, it is wrapped as a vport like all other physical ports. The DPDK > app/OVS will treat all ports equally. That is not true. Currently vhost in Open vSwitch implemented as a separate netdev class. So, to use concurrency of vhost we just need to remove 2 lines (rte_spinlock_lock and rte_spinlock_unlock) from function __netdev_dpdk_vhost_send(). This will not change behaviour of other types of ports. > It will add complexity if the app > needs to know that some supports concurrency while some not. Since all > other PMDs doesn't support thread safety, it doesn't make sense for > vhost PMD to support that. I believe the APP will not use that behavior. >>>From the API's point of view, if we previously implemented it wrongly, > we need to fix it as early as possible.