From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id 2F8638D8D for ; Fri, 18 Dec 2015 10:25:51 +0100 (CET) Received: by mail-pf0-f180.google.com with SMTP id n128so28540059pfn.0 for ; Fri, 18 Dec 2015 01:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=TWaITGw7HBjcLlVMqqKz3vU9c7yboYWHDfB8w97MGmc=; b=CS/ajHtDXUJ8ga5R0F+6hYPM6qy5XAMxOtgogcUF0rgt/JgUurXV3aQOS6DGl6DjlH BYsBwNrL6yFcKkYuzE2KItmqTzt0UTS7ioVAzMzluPeAchxIqVr6vBGGwofd5hVWVYf2 a9Xj73i0iNxEtsTQow3BkCr3X6Rxmb9B3y++UQGb2lkFobvBl4ykQDMdTv5IAgzUMLdr 7xGOdoGujhivSHE9TT2DMQgUaQ+uHA5FpfIsbRZZHyS0rab7QL13QGkfJoozK4TvJCAT V8Epv5LEGP8CekiT5CnCnoaageHqVhMiC8ix3kVfJM1m3XyvmR50VZTAIvmMVFroGhGP YyrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=TWaITGw7HBjcLlVMqqKz3vU9c7yboYWHDfB8w97MGmc=; b=YC0XL2XjTPwI6OoT4vzxNSku3+mdSHs7qijiUAHtgnVGfH4rnV3B4+KBd3eXsxa7J7 ZrQTpUIEW00s2Tf+KUtsUv+KCrFa8Cyp8rTKg/ax5pL2WqZjsxPzbkkzaypLZTZ7y417 wTBnRlZOXdfhy1aQ7o3i9tP17S5mvHvzCxmoYfHg51HI3qbH2wUlqXjQpuY7dQAqPyfY rgxQS/hPpf0dEO4j62hGQVreL3h1Rv5757MZRUgn8HGpvFMHNNFVbdvxLIzeVExW1Oj5 zNcyxzgjffb/rE3a5O3gvtfzamEg/1HfVFdOJWXWdDBXBYnUZVWkoYP2Is2t/dMLgcB5 rZ9Q== X-Gm-Message-State: ALoCoQkpp+UVqarYQKjkaJaU9GKQ5G0vLiBaenCsYMBTco3x8Sx9bnQj7h47/hTpp8cVTJwJg1LycTojRb4qYuvL1/ylDrVT7g== X-Received: by 10.98.10.131 with SMTP id 3mr3627654pfk.105.1450430750482; Fri, 18 Dec 2015 01:25:50 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id by2sm20958634pab.20.2015.12.18.01.25.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 01:25:49 -0800 (PST) To: Yuanhan Liu , "Xie, Huawei" References: <1447392031-24970-3-git-send-email-mukawa@igel.co.jp> <1448355603-21275-1-git-send-email-mukawa@igel.co.jp> <1448355603-21275-3-git-send-email-mukawa@igel.co.jp> <20151218074512.GA18863@yliu-dev.sh.intel.com> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <5673D11B.7030801@igel.co.jp> Date: Fri, 18 Dec 2015 18:25:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151218074512.GA18863@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, ann.zhuangyanying@huawei.com, yuanhan.liu@intel.com Subject: Re: [dpdk-dev] [PATCH v5 2/3] vhost: Add VHOST PMD 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: Fri, 18 Dec 2015 09:25:51 -0000 On 2015/12/18 16:45, Yuanhan Liu wrote: > On Tue, Nov 24, 2015 at 06:00:02PM +0900, Tetsuya Mukawa wrote: >> +static uint16_t >> +eth_vhost_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs) >> +{ >> + struct vhost_queue *r = q; >> + uint16_t i, nb_rx = 0; >> + >> + if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0)) >> + return 0; >> + >> + rte_atomic32_set(&r->while_queuing, 1); >> + >> + if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0)) >> + goto out; > I'm not quite famililar with PMD driver yet, but as far as I know, > rte_eth_rx/tx_burst() does not provide any garantee on concurrent > dequeuing/queuing. If that's true, vhost pmd could (and should) > not do that, to keep the consistency. Yes you are correct, but this checking isn't for that purpose. I guess there is no rule that DPDK application should not call rte_eth_rx/tx_burst() when link status is down. So the application may call rte_eth_rx/tx_burst() even when vhost backend connection isn't established. Not to call rte_vhost_dequeue_burst() in the case, above variables are used. Tetsuya > On the other hand, rte_vhost_dequeue/enqueue_burst() already has > such support since the beginning: above check is redundant then. > However, FYI, Huawei has just (internally) proposed to remove > it, as he thinks that's application's duty. > > So, in neither way, we should not do that. > > --yliu