From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yuanhan.liu@linux.intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 3B361B62
 for <dev@dpdk.org>; Wed, 23 Dec 2015 03:43:51 +0100 (CET)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by orsmga101.jf.intel.com with ESMTP; 22 Dec 2015 18:43:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,467,1444719600"; d="scan'208";a="879457141"
Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49])
 by fmsmga002.fm.intel.com with ESMTP; 22 Dec 2015 18:43:31 -0800
Date: Wed, 23 Dec 2015 10:44:53 +0800
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Rich Lane <rich.lane@bigswitch.com>,
 Thomas Monjalon <thomas.monjalon@6wind.com>
Message-ID: <20151223024453.GW18863@yliu-dev.sh.intel.com>
References: <1448355603-21275-2-git-send-email-mukawa@igel.co.jp>
 <20151217114223.GC29571@yliu-dev.sh.intel.com>
 <56737A5E.1030803@igel.co.jp>
 <20151218041536.GI29571@yliu-dev.sh.intel.com>
 <56738B5C.1030206@igel.co.jp>
 <CAGSMBPPGs8b3sGAn6A2ETaau70oeChouTOnj=Ah2sgjz_1p_nA@mail.gmail.com>
 <20151222034158.GH18863@yliu-dev.sh.intel.com>
 <CAGSMBPMHhCOmRJ9aQEmdtBeBBcokztmdHyXC5BBnQ-rXF0OkYg@mail.gmail.com>
 <20151222054710.GK18863@yliu-dev.sh.intel.com>
 <CAGSMBPNrjzcJGrgPfxo+EBj=uuxV9Q_prXDDSB5HxwcmU0R_PQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAGSMBPNrjzcJGrgPfxo+EBj=uuxV9Q_prXDDSB5HxwcmU0R_PQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 <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: Wed, 23 Dec 2015 02:43:51 -0000

On Tue, Dec 22, 2015 at 01:38:29AM -0800, Rich Lane wrote:
> On Mon, Dec 21, 2015 at 9:47 PM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
> wrote:
> 
>     On Mon, Dec 21, 2015 at 08:47:28PM -0800, Rich Lane wrote:
>     > The queue state change callback is the one new API that needs to be
>     > added because
>     > normal NICs don't have this behavior.
> 
>     Again I'd ask, will vring_state_changed() be enough, when above issues
>     are resolved: vring_state_changed() will be invoked at new_device()/
>     destroy_device(), and of course, ethtool change?
> 
> 
> It would be sufficient. It is not a great API though, because it requires the
> application to do the conversion from struct virtio_net to a DPDK port number,
> and from a virtqueue index to a DPDK queue id and direction. Also, the current
> implementation often makes this callback when the vring state has not actually
> changed (enabled -> enabled and disabled -> disabled).
> 
> If you're asking about using vring_state_changed() _instead_ of the link status
> event and rte_eth_dev_socket_id(),

No, I like the idea of link status event and rte_eth_dev_socket_id();
I was just wondering why a new API is needed. Both Tetsuya and I
were thinking to leverage the link status event to represent the
queue stats change (triggered by vring_state_changed()) as well,
so that we don't need to introduce another eth event. However, I'd
agree that it's better if we could have a new dedicate event.

Thomas, here is some background for you. For vhost pmd and linux
virtio-net combo, the queue can be dynamically changed by ethtool,
therefore, the application wishes to have another eth event, say
RTE_ETH_EVENT_QUEUE_STATE_CHANGE, so that the application can
add/remove corresponding queue to the datapath when that happens.
What do you think of that?

> then yes, it still works. I'd only consider
> that a stopgap until the real ethdev APIs are implemented.
> 
> I'd suggest to add RTE_ETH_EVENT_QUEUE_STATE_CHANGE rather than
> create another callback registration API.
> 
> Perhaps we could merge the basic PMD which I think is pretty solid and then
> continue the API discussion with patches to it.

Perhaps, but let's see how hard it could be for the new eth event
discussion then.

	--yliu