From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <i.maximets@samsung.com> Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id 7E6625586 for <dev@dpdk.org>; Fri, 18 Mar 2016 10:55:20 +0100 (CET) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O48002ZMBK6QZ70@mailout3.w1.samsung.com> for dev@dpdk.org; Fri, 18 Mar 2016 09:55:19 +0000 (GMT) X-AuditID: cbfec7f5-f79b16d000005389-a8-56ebd086c4d8 Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 2B.C9.21385.680DBE65; Fri, 18 Mar 2016 09:55:18 +0000 (GMT) Received: from [106.109.129.180] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O48009DRBK5US30@eusync2.samsung.com>; Fri, 18 Mar 2016 09:55:18 +0000 (GMT) To: Yuanhan Liu <yuanhan.liu@linux.intel.com>, Thomas Monjalon <thomas.monjalon@6wind.com> References: <1456314438-4021-1-git-send-email-i.maximets@samsung.com> <9470086.ZYvecjaNVJ@xps13> <20160318091614.GT979@yliu-dev.sh.intel.com> <3519170.fnd0yd7nVF@xps13> <20160318094642.GA23215@yliu-dev.sh.intel.com> Cc: dev@dpdk.org, Huawei Xie <huawei.xie@intel.com>, bruce.richardson@intel.com, Dyasly Sergey <s.dyasly@samsung.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com>, Jianbo Liu <jianbo.liu@linaro.org>, Tetsuya Mukawa <mukawa@igel.co.jp> From: Ilya Maximets <i.maximets@samsung.com> Message-id: <56EBD085.4030500@samsung.com> Date: Fri, 18 Mar 2016 12:55:17 +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: <20160318094642.GA23215@yliu-dev.sh.intel.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsVy+t/xK7ptF16HGRw7aGlxY5W9xbtP25ks 2meeZbKYOMnEYvrTCItjPZ9YLSbPlrL4smk6m8X1CRdYHTg9LvbfYfTYcKKf1ePXgqWsHo3P JTwW73nJ5HHn2h42j3knAz36tqxiDOCI4rJJSc3JLEst0rdL4MqYdXk5S8FFoYoLpx8zNjB+ 4+ti5OSQEDCRuHillRHCFpO4cG89WxcjF4eQwFJGiaV9s1ggnBeMEgf/rGMGqRIWCJZYsek4 K4gtIhAjMeH6BVaIotuMEqf29LKDJJgFPjJKLJ6UCWKzCehInFp9BGwFr4CWxMqzS1hAbBYB VYmJx26wgdiiAhEShzu72CFqBCV+TL4HVsMpYC2xY+MXpi5GDqCZehL3L2pBjJeX2LzmLfME RoFZSDpmIVTNQlK1gJF5FaNoamlyQXFSeq6RXnFibnFpXrpecn7uJkZINHzdwbj0mNUhRgEO RiUe3hdVr8OEWBPLiitzDzFKcDArifB+OQcU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjtz1/sQ IYH0xJLU7NTUgtQimCwTB6dUA2PN5V3TC4QvrLR8G/qLP9/klNmN9Ky/C5xWVRzeIGmlOHde a3l/xNv5NXYXc/ZVv7h4YKdvofz9+I/X/HOk7tiWrX/Km/kr5uRlcw7+facYDlb3Hcz5tlb2 APe5S8sqHGoPMKzyfjLlh7spv8FyicVuidXNR4U4dz6xbphpzhx11H/RtkqOXSZKLMUZiYZa zEXFiQByktMiggIAAA== Subject: Re: [dpdk-dev] [PATCH RFC v3 0/3] Thread safe rte_vhost_enqueue_burst(). X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 18 Mar 2016 09:55:20 -0000 On 18.03.2016 12:46, Yuanhan Liu wrote: > On Fri, Mar 18, 2016 at 10:34:56AM +0100, Thomas Monjalon wrote: >> 2016-03-18 17:16, Yuanhan Liu: >>> On Fri, Mar 18, 2016 at 09:09:04AM +0100, Thomas Monjalon wrote: >>>> 2016-03-18 16:00, Yuanhan Liu: >>>>> On Thu, Mar 17, 2016 at 04:29:32PM +0100, Thomas Monjalon wrote: >>>>>> 2016-02-24 14:47, Ilya Maximets: >>>>>>> Implementation of rte_vhost_enqueue_burst() based on lockless ring-buffer >>>>>>> algorithm and contains almost all to be thread-safe, but it's not. >>>>>>> >>>>>>> This set adds required changes. >>>>>>> >>>>>>> First patch in set is a standalone patch that fixes many times discussed >>>>>>> issue with barriers on different architectures. >>>>>>> >>>>>>> Second and third adds fixes to make rte_vhost_enqueue_burst thread safe. >>>>>> >>>>>> My understanding is that we do not want to pollute Rx/Tx with locks. >>>>>> >>>>>> Huawei, Yuanhan, Bruce, do you confirm? >>>>> >>>>> Huawei would like to do that, and I'm behind that. Let's do it. >>>> >>>> I'm not sure to understand. What do you want to do exactly? >>> >>> I was thinking we are on the same page :( >> >> Yes we are on the same page. >> But it's better to make things explicit. >> >> There should be no lock in Rx/Tx drivers (including vhost). >> The locking must be done by the caller (application level). > > Yeah, that's why Huawei made the proposal and the patch. > >> That's why this series "Thread safe rte_vhost_enqueue_burst" is rejected. Hi all. And what about first patch of this series: "vhost: use SMP barriers instead of compiler ones." ? It's not about thread safety in terms of 'lockless'. It is the standalone patch that fixes many times discussed issue with barriers on arm. Best regards, Ilya Maximets. >> >>> "do not want to pollute Rx/Tx with locks" == "remove lockless Rx/Tx, the >>> proposal from Huawei", right? >>> >>> In another way, I'm behind the following patch from Huawei: >>> >>> http://dpdk.org/dev/patchwork/patch/9740/ >> >> The patch "vhost: remove lockless enqueue to the virtio ring" must me >> reworked in 2 patches: >> 1/ announce API change > > That was my concern, and agreed we need that. > >> 2/ remove locks >> >> Please avoid talking about removing "lockless" when actually removing locks. > > Sorry, my bad. > > --yliu > >