From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Subject: Re: [PATCH 03/17] vhost: use new APIs to handle features
Date: Fri, 17 Mar 2017 13:48:49 +0800
Message-ID: <20170317054849.GD18844@yliu-dev.sh.intel.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>
 <54aee9bd-ae85-9565-0bcd-c30346c9fa38@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 mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id 688812BA1
 for <dev@dpdk.org>; Fri, 17 Mar 2017 06:50:37 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <54aee9bd-ae85-9565-0bcd-c30346c9fa38@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:39:00AM +0100, Maxime Coquelin wrote:
> 
> 
> 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?

Yes, I think we could do that. Thanks!

	--yliu