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 BC22AE72 for ; Fri, 18 Dec 2015 04:36:52 +0100 (CET) Received: by mail-pf0-f180.google.com with SMTP id 68so41508426pfc.1 for ; Thu, 17 Dec 2015 19:36:52 -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=MwAWwRtlzoPYRYt2ODX/Aem1w4gJGdnjGLGeBWf1Mjg=; b=v9o88K+veH48SiRvX53zIEznhtd66ERNJtkSd0D/ID2vByYnGn6nsXg9mZvqgcT6c8 GQQC2qFHq5s8FdZUP4KtkuIMA5JgjOpnDgLOeeO1w/bYkj+XNtim18yYNtrHbBP4nvd9 XtbMR8ZvPCgjaSXxObni1JXpCmkTPG7giLSPjLPNhL2IuhICtD5PG9dl4c8WE9B8Xfbj 16TSeRj/uhLzLnC44z9xa2t4Y6qmsSEGBLTCgynaWXiL/ySdybfkcavUgrxGKHx9bWLf vJtVZeGW4DqY74U0Um3LYEwQJmCC8bmt8H7JpQ1j9mk2z9uRO5xLaGda7FeUghC7xCsw xqOQ== 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=MwAWwRtlzoPYRYt2ODX/Aem1w4gJGdnjGLGeBWf1Mjg=; b=ABZG2hp4nXZph9CtK0giaODs8zZiABQmyE8DjOY7JVPncVdJNt58do+zSu8lpUBZjp MzTa3+HVgWA0CVyPk3VT04bNmj8qCD5VN2bWiQMiTr9/N4RAq90BzqXdlHMV0lI6e+4U 0RjHIpPVdMC8CkdKQpcJhg3Qoj3aWsGJBtS8PvEFd38K0f18CSBa3lTmAO/9YajLpHO9 7IkhwkcS4hJHMNWMhY40CfthgUCVBnsBoSPAZGcdzN81vWRdg7+thmtvO51INBH7QZUI UGW2v5y+2GPP1yAQoBV31sQinL5ksSXf8C90uqLmsHwYAlTigQihn6SMPevrtTbtmsdC pwyg== X-Gm-Message-State: ALoCoQnP431GJ6XZ70ynXsXiRJkb4CWY1EeULserXYLv0N1mQpiJv9X0Td6gVrvFv+kZYTP/cgAfFT9yLta0YqI91z1cLE9BAg== X-Received: by 10.98.72.71 with SMTP id v68mr1932826pfa.17.1450409812018; Thu, 17 Dec 2015 19:36:52 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id g10sm14215545pfj.15.2015.12.17.19.36.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 19:36:51 -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-2-git-send-email-mukawa@igel.co.jp> <20151217114223.GC29571@yliu-dev.sh.intel.com> <56737A5E.1030803@igel.co.jp> From: Tetsuya Mukawa Message-ID: <56737F50.5060609@igel.co.jp> Date: Fri, 18 Dec 2015 12:36:48 +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: <56737A5E.1030803@igel.co.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, ann.zhuangyanying@huawei.com Subject: Re: [dpdk-dev] [PATCH v5 1/3] vhost: Add callback and private data for 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 03:36:53 -0000 On 2015/12/18 12:15, Tetsuya Mukawa wrote: > On 2015/12/17 20:42, Yuanhan Liu wrote: >> On Tue, Nov 24, 2015 at 06:00:01PM +0900, Tetsuya Mukawa wrote: >>> The vhost PMD will be a wrapper of vhost library, but some of vhost >>> library APIs cannot be mapped to ethdev library APIs. >>> Becasue of this, in some cases, we still need to use vhost library APIs >>> for a port created by the vhost PMD. >>> >>> Currently, when virtio device is created and destroyed, vhost library >>> will call one of callback handlers. The vhost PMD need to use this >>> pair of callback handlers to know which virtio devices are connected >>> actually. >>> Because we can register only one pair of callbacks to vhost library, if >>> the PMD use it, DPDK applications cannot have a way to know the events. >>> >>> This may break legacy DPDK applications that uses vhost library. To prevent >>> it, this patch adds one more pair of callbacks to vhost library especially >>> for the vhost PMD. >>> With the patch, legacy applications can use the vhost PMD even if they need >>> additional specific handling for virtio device creation and destruction. >>> >>> For example, legacy application can call >>> rte_vhost_enable_guest_notification() in callbacks to change setting. >> TBH, I never liked it since the beginning. Introducing two callbacks >> for one event is a bit messy, and therefore error prone. > I agree with you. > >> I have been thinking this occasionally last few weeks, and have came >> up something that we may introduce another layer callback based on >> the vhost pmd itself, by a new API: >> >> rte_eth_vhost_register_callback(). >> >> And we then call those new callback inside the vhost pmd new_device() >> and vhost pmd destroy_device() implementations. >> >> And we could have same callbacks like vhost have, but I'm thinking >> that new_device() and destroy_device() doesn't sound like a good name >> to a PMD driver. Maybe a name like "link_state_changed" is better? >> >> What do you think of that? > Yes, "link_state_changed" will be good. > > BTW, I thought it was ok that an DPDK app that used vhost PMD called > vhost library APIs directly. > But probably you may feel strangeness about it. Is this correct? > > If so, how about implementing legacy status interrupt mechanism to vhost > PMD? > For example, an DPDK app can register callback handler like > "examples/link_status_interrupt". Addition: In this case, we don't need something special pmd_priv field in vhost library. vhost PMD will register callbacks. And in this callbacks, legacy interrupt mechanism will be kicked. Then user can receive interrupt from ethdev. Tetsuya > Also, if the app doesn't call vhost library APIs directly, > rte_eth_vhost_portid2vdev() will be needless, because the app doesn't > need to handle virtio device structure anymore. > >> >> On the other hand, I'm still thinking is that really necessary to let >> the application be able to call vhost functions like rte_vhost_enable_guest_notification() >> with the vhost PMD driver? > Basic concept of my patch is that vhost PMD will provides the features > that vhost library provides. > > How about removing rte_vhost_enable_guest_notification() from "vhost > library"? > (I also not sure what are use cases) > If we can do this, vhost PMD also doesn't need to take care of it. > Or if rte_vhost_enable_guest_notification() will be removed in the > future, vhost PMD is able to ignore it. > > > Please let me correct up my thinking about your questions. > - Change concept of patch not to call vhost library APIs directly. > These should be wrapped by ethdev APIs. > - Remove rte_eth_vhost_portid2vdev(), because of above concept changing. > - Implement legacy status changed interrupt to vhost PMD instead of > using own callback mechanism. > - Check if we can remove rte_vhost_enable_guest_notification() from > vhost library. > > > Hi Xie, > > Do you know the use cases of rte_vhost_enable_guest_notification()? > > Thanks, > Tetsuya