From mboxrd@z Thu Jan  1 00:00:00 1970
From: Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [PATCH 06/17] vhost: introduce API to fetch
	negotiated features
Date: Thu, 16 Mar 2017 10:22:27 +0100
Message-ID: <de40ac38-a79a-6154-a39d-c5ed6804ec6b@redhat.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, Harris James R <james.r.harris@intel.com>,
 Liu Changpeng <changpeng.liu@intel.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id 244141075
 for <dev@dpdk.org>; Thu, 16 Mar 2017 10:22:34 +0100 (CET)
In-Reply-To: <20170316073516.GQ18844@yliu-dev.sh.intel.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 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).

Thanks,
Maxime