From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tetsuya Mukawa Subject: Re: [PATCH v2 2/2] vhost: Add VHOST PMD Date: Fri, 6 Nov 2015 12:54:34 +0900 Message-ID: <563C247A.6050108@igel.co.jp> 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> <20151106022235.GD2326@yliu-dev.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, ann.zhuangyanying@huawei.com To: Yuanhan Liu , "Michael S. Tsirkin" Return-path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id 3022E8DA1 for ; Fri, 6 Nov 2015 04:54:39 +0100 (CET) Received: by pabfh17 with SMTP id fh17so108367891pab.0 for ; Thu, 05 Nov 2015 19:54:38 -0800 (PST) In-Reply-To: <20151106022235.GD2326@yliu-dev.sh.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 2015/11/06 11:22, Yuanhan Liu wrote: > 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. Hi Liu, Oops, I've found a bug here. To support multiple queues in vhost PMD, I needed to store "queue_id" in "vhost_queue" structure. Then, I should call rte_vhost_enqueue_burst() with the value. > 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. I may not understand the steering function enough, but If we support the steering function in vhost library or vhost PMD, how can we handle "queue_id" parameter of TX functions? Probably, we need to ignore the value In some cases. This may confuse the users because they cannot observe the packets in their specified queue. So I guess it may be application responsibility to return packets to the correct queue. (But we should write a correct documentation about it) > 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 > Thanks, I've checked it! Tetsuya