From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yuanhan.liu@linux.intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id AAD278D89
 for <dev@dpdk.org>; Fri,  6 Nov 2015 03:19:38 +0100 (CET)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by orsmga102.jf.intel.com with ESMTP; 05 Nov 2015 18:19:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,250,1444719600"; d="scan'208";a="828515939"
Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49])
 by fmsmga001.fm.intel.com with ESMTP; 05 Nov 2015 18:19:36 -0800
Date: Fri, 6 Nov 2015 10:22:35 +0800
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Tetsuya Mukawa <mukawa@igel.co.jp>, "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20151106022235.GD2326@yliu-dev.sh.intel.com>
References: <1445926375-18986-4-git-send-email-mukawa@igel.co.jp>
 <1446436737-25606-1-git-send-email-mukawa@igel.co.jp>
 <1446436737-25606-3-git-send-email-mukawa@igel.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1446436737-25606-3-git-send-email-mukawa@igel.co.jp>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dev@dpdk.org, ann.zhuangyanying@huawei.com
Subject: Re: [dpdk-dev] [PATCH v2 2/2] vhost: Add VHOST PMD
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, 06 Nov 2015 02:19:39 -0000

On Mon, Nov 02, 2015 at 12:58:57PM +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 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;
> +
> +	/* Dequeue packets from guest TX queue */
> +	nb_rx = (uint16_t)rte_vhost_dequeue_burst(r->device,
> +			VIRTIO_TXQ, r->mb_pool, bufs, nb_bufs);
> +
> +	r->rx_pkts += nb_rx;
> +
> +out:
> +	rte_atomic32_set(&r->while_queuing, 0);
> +
> +	return nb_rx;
> +}
> +
> +static uint16_t
> +eth_vhost_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
> +{
> +	struct vhost_queue *r = q;
> +	uint16_t i, nb_tx = 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;
> +
> +	/* Enqueue packets to guest RX queue */
> +	nb_tx = (uint16_t)rte_vhost_enqueue_burst(r->device,
> +			VIRTIO_RXQ, bufs, nb_bufs);
> +

Michael, I'm wondering here might be the better place to do "automatic
receive steering in multiqueue mode". I mean, as a library function,
queueing/dequeueing packets to/from a specific virt queue is reasonable
to me. It's upto the caller to pick the right queue, doing the queue
steering.

As an eth dev, I guess that's the proper place to do things like that.

Or, I'm thinking we could introduce another vhost function, for not
breaking current API, to do that, returning the right queue, so that
other applications (instead of the vhost pmd only) can use that as well.

Tetsuya, just in case you missed the early discussion about automic
receive steering, here is a link:

  http://dpdk.org/ml/archives/dev/2015-October/025779.html


	--yliu