From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Subject: Re: [PATCH 06/17] vhost: introduce API to fetch
	negotiated features
Date: Fri, 17 Mar 2017 13:49:28 +0800
Message-ID: <20170317054928.GE18844@yliu-dev.sh.intel.com>
References: <1488534682-3494-1-git-send-email-yuanhan.liu@linux.intel.com>
 <1488534682-3494-7-git-send-email-yuanhan.liu@linux.intel.com>
 <c220e842-dad4-0430-175b-f98c5b5a24e0@redhat.com>
 <20170316073516.GQ18844@yliu-dev.sh.intel.com>
 <de40ac38-a79a-6154-a39d-c5ed6804ec6b@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org, Harris James R <james.r.harris@intel.com>,
 Liu Changpeng <changpeng.liu@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id 2871E11DE
 for <dev@dpdk.org>; Fri, 17 Mar 2017 06:51:15 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <de40ac38-a79a-6154-a39d-c5ed6804ec6b@redhat.com>
List-Id: DPDK patches and discussions <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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Thu, Mar 16, 2017 at 10:22:27AM +0100, Maxime Coquelin wrote:
> 
> 
> On 03/16/2017 08:35 AM, Yuanhan Liu wrote:
> >On Tue, Mar 14, 2017 at 12:02:59PM +0100, Maxime Coquelin wrote:
> >>>+uint64_t
> >>>+rte_vhost_get_negotiated_features(int vid)
> >>>+{
> >>>+	struct virtio_net *dev;
> >>>+
> >>>+	dev = get_device(vid);
> >>>+	if (!dev)
> >>>+		return -1;
> >>>+
> >>>+	return dev->features;
> >>>+}
> >>Are we sure the negotiation is done when we can get the device?
> >
> >Yes. However, one thing worth noting is that the features may change
> >after the new_device() callback. Notablely, when live migration starts
> >/ends, the VHOST_F_LOG_ALL will be set/cleared, respectively.
> 
> Good point.
> 
> >From that point of view, we need a new callback, something like
> >features_changed(), or live_migration_starts()? Or a better name?
> 
> I would name it features_changed() to be future-proof (even if I don't
> foresee other cases than live migration right now).

Right, it will be "features_changed()" then.

	--yliu