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
