From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <huawei.xie@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id F21135A62 for <dev@dpdk.org>; Tue, 19 Jan 2016 17:44:01 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 19 Jan 2016 08:44:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,318,1449561600"; d="scan'208";a="896606942" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 19 Jan 2016 08:43:59 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 19 Jan 2016 08:43:58 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.215]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.209]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 00:43:56 +0800 From: "Xie, Huawei" <huawei.xie@intel.com> To: "Tan, Jianfeng" <jianfeng.tan@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Thread-Topic: [PATCH] vhost: remove lockless enqueue to the virtio ring Thread-Index: AdFS2JXTbfKrEVXJ2kay2UtF3JDFnQ== Date: Tue, 19 Jan 2016 16:43:55 +0000 Message-ID: <C37D651A908B024F974696C65296B57B4C5A475A@SHSMSX101.ccr.corp.intel.com> References: <1451918787-85887-1-git-send-email-huawei.xie@intel.com> <569E6372.5030200@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ann.zhuangyanying@huawei.com" <ann.zhuangyanying@huawei.com> Subject: Re: [dpdk-dev] [PATCH] vhost: remove lockless enqueue to the virtio ring 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: Tue, 19 Jan 2016 16:44:02 -0000 On 1/20/2016 12:25 AM, Tan, Jianfeng wrote:=0A= > Hi Huawei,=0A= >=0A= > On 1/4/2016 10:46 PM, Huawei Xie wrote:=0A= >> This patch removes the internal lockless enqueue implmentation.=0A= >> DPDK doesn't support receiving/transmitting packets from/to the same=0A= >> queue. Vhost PMD wraps vhost device as normal DPDK port. DPDK=0A= >> applications normally have their own lock implmentation when enqueue=0A= >> packets to the same queue of a port.=0A= >>=0A= >> The atomic cmpset is a costly operation. This patch should help=0A= >> performance a bit.=0A= >>=0A= >> Signed-off-by: Huawei Xie <huawei.xie@intel.com>=0A= >> ---=0A= >> lib/librte_vhost/vhost_rxtx.c | 86=0A= >> +++++++++++++------------------------------=0A= >> 1 file changed, 25 insertions(+), 61 deletions(-)=0A= >>=0A= >> diff --git a/lib/librte_vhost/vhost_rxtx.c=0A= >> b/lib/librte_vhost/vhost_rxtx.c=0A= >> index bbf3fac..26a1b9c 100644=0A= >> --- a/lib/librte_vhost/vhost_rxtx.c=0A= >> +++ b/lib/librte_vhost/vhost_rxtx.c=0A= >=0A= > I think vhost example will not work well with this patch when=0A= > vm2vm=3Dsoftware.=0A= >=0A= > Test case:=0A= > Two virtio ports handled by two pmd threads. Thread 0 polls pkts from=0A= > physical NIC and sends to virtio0, while thread0 receives pkts from=0A= > virtio1 and routes it to virtio0.=0A= =0A= vhost port will be wrapped as port, by vhost PMD. DPDK APP treats all=0A= physical and virtual ports as ports equally. When two DPDK threads try=0A= to enqueue to the same port, the APP needs to consider the contention.=0A= All the physical PMDs doesn't support concurrent enqueuing/dequeuing.=0A= Vhost PMD should expose the same behavior unless absolutely necessary=0A= and we expose the difference of different PMD.=0A= =0A= >=0A= >> -=0A= >> *(volatile uint16_t *)&vq->used->idx +=3D entry_success;=0A= >=0A= > Another unrelated question: We ever try to move this assignment out of=0A= > loop to save cost as it's a data contention?=0A= =0A= This operation itself is not that costly, but it has side effect on the=0A= cache transfer.=0A= It is outside of the loop for non-mergable case. For mergeable case, it=0A= is inside the loop.=0A= Actually it has pro and cons whether we do this in burst or in a smaller=0A= step. I prefer to move it outside of the loop. Let us address this later.= =0A= =0A= >=0A= > Thanks,=0A= > Jianfeng=0A= >=0A= >=0A= =0A=