From mboxrd@z Thu Jan  1 00:00:00 1970
From: Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [PATCH 03/17] vhost: use new APIs to handle features
Date: Thu, 16 Mar 2017 10:39:00 +0100
Message-ID: <54aee9bd-ae85-9565-0bcd-c30346c9fa38@redhat.com>
References: <1488534682-3494-1-git-send-email-yuanhan.liu@linux.intel.com>
 <1488534682-3494-4-git-send-email-yuanhan.liu@linux.intel.com>
 <b9b581b0-efd1-51a0-e3f7-4fec7460ea50@redhat.com>
 <20170316074311.GR18844@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 E49A31396
 for <dev@dpdk.org>; Thu, 16 Mar 2017 10:39:04 +0100 (CET)
In-Reply-To: <20170316074311.GR18844@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:43 AM, Yuanhan Liu wrote:
> On Tue, Mar 14, 2017 at 11:43:44AM +0100, Maxime Coquelin wrote:
>>> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
>>> index 8433a54..f7227bf 100644
>>> --- a/lib/librte_vhost/vhost_user.c
>>> +++ b/lib/librte_vhost/vhost_user.c
>>> @@ -143,9 +143,9 @@
>>>  * The features that we support are requested.
>>>  */
>>> static uint64_t
>>> -vhost_user_get_features(void)
>>> +vhost_user_get_features(struct virtio_net *dev)
>>> {
>>> -	return VHOST_FEATURES;
>>> +	return rte_vhost_driver_get_features(dev->ifname);
>>> }
>>>
>>> /*
>>> @@ -154,7 +154,7 @@
>>> static int
>>> vhost_user_set_features(struct virtio_net *dev, uint64_t features)
>>> {
>>> -	if (features & ~VHOST_FEATURES)
>>> +	if (features & ~rte_vhost_driver_get_features(dev->ifname))
>>
>> rte_vhost_driver_get_features() returns -1 if the socket is not found.
>> It would result in accepting any feature trying to be set.
>
> If we have gone here, I think rte_vhost_driver_get_features() should not
> return -1. The only exception is user unregistered such socket during
> the negotiation?

Maybe this could never happen.
I just noticed that rte_vhost_driver_get_features() can fail, and in
that case, we wouldn't see it and the behavior could make hard the
cause to be hard to spot.

As this is not in the hot code path, my view is that checking its return 
and print an error message does not hurt.

Or maybe we could directly do the error prints into
rte_vhost_driver_*_features() functions if the socket name is not found?

Cheers,
Maxime