From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [PATCH 3/5] net/virtio-user: support to report net status Date: Thu, 30 Mar 2017 11:14:55 +0800 Message-ID: <5a59e0ab-617e-2e5e-60a0-6835d74e5c3e@intel.com> References: <1488563803-87754-1-git-send-email-jianfeng.tan@intel.com> <1488563803-87754-4-git-send-email-jianfeng.tan@intel.com> <20170317065445.GH18844@yliu-dev.sh.intel.com> <20170329063301.GE18844@yliu-dev.sh.intel.com> <29d1e442-1c5b-6ba0-dbf1-9d35d36e37e1@intel.com> <20170329071423.GH18844@yliu-dev.sh.intel.com> <006baeef-4167-edcf-407a-e149e01e8d65@intel.com> <20170329080028.GJ18844@yliu-dev.sh.intel.com> <908853b1-5910-7153-25b0-0233f610053e@intel.com> <20170329083659.GK18844@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" , "david.marchand@6wind.com" To: Yuanhan Liu Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id EDC82FC33 for ; Thu, 30 Mar 2017 05:14:57 +0200 (CEST) In-Reply-To: <20170329083659.GK18844@yliu-dev.sh.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 3/29/2017 4:36 PM, Yuanhan Liu wrote: > On Wed, Mar 29, 2017 at 04:33:20PM +0800, Tan, Jianfeng wrote: >> >> On 3/29/2017 4:00 PM, Yuanhan Liu wrote: >>> On Wed, Mar 29, 2017 at 03:48:04PM +0800, Tan, Jianfeng wrote: >>>> On 3/29/2017 3:14 PM, Yuanhan Liu wrote: >>>>> On Wed, Mar 29, 2017 at 03:07:28PM +0800, Tan, Jianfeng wrote: >>>>>> On 3/29/2017 2:33 PM, Yuanhan Liu wrote: >>>>>>> On Mon, Mar 27, 2017 at 07:46:32AM +0000, Tan, Jianfeng wrote: >>>>>>>>>> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c >>>>>>>>> b/drivers/net/virtio/virtio_user/virtio_user_dev.c >>>>>>>>>> index 9777d6b..cc6f557 100644 >>>>>>>>>> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c >>>>>>>>>> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c >>>>>>>>>> @@ -176,6 +176,7 @@ virtio_user_start_device(struct virtio_user_dev >>>>>>>>> *dev, uint8_t portid) >>>>>>>>>> features &= ~(1ull << VIRTIO_NET_F_MAC); >>>>>>>>>> /* Strip VIRTIO_NET_F_CTRL_VQ, as devices do not really need to >>>>>>>>> know */ >>>>>>>>>> features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ); >>>>>>>>>> + features &= ~(1ull << VIRTIO_NET_F_STATUS); >>>>>>>>>> ret = dev->ops->send_request(dev, VHOST_USER_SET_FEATURES, >>>>>>>>> &features); >>>>>>>>>> if (ret < 0) >>>>>>>>>> goto error; >>>>>>>>>> diff --git a/drivers/net/virtio/virtio_user_ethdev.c >>>>>>>>> b/drivers/net/virtio/virtio_user_ethdev.c >>>>>>>>>> index fa79419..fbdd0a8 100644 >>>>>>>>>> --- a/drivers/net/virtio/virtio_user_ethdev.c >>>>>>>>>> +++ b/drivers/net/virtio/virtio_user_ethdev.c >>>>>>>>>> @@ -121,7 +121,8 @@ virtio_user_get_features(struct virtio_hw *hw) >>>>>>>>>> struct virtio_user_dev *dev = virtio_user_get_dev(hw); >>>>>>>>>> >>>>>>>>>> /* unmask feature bits defined in vhost user protocol */ >>>>>>>>>> - return dev->device_features & >>>>>>>>> VIRTIO_PMD_SUPPORTED_GUEST_FEATURES; >>>>>>>>>> + return (dev->device_features | (1 << VIRTIO_NET_F_STATUS)) >>>>>>>>>> + & VIRTIO_PMD_SUPPORTED_GUEST_FEATURES; >>>>>>>>> Why not handle the features at virtio_user_dev_init()? >>>>>>>> You mean add VIRTIO_NET_F_STATUS when get_features from device? Yes, we could do that there. But we originally add device_features to only record features supported by device. >>>>>>>> >>>>>>> Aren't you adding the F_STATUS features to this device? >>>>>>> >>>>>> For virtio driver, yes, we are adding F_STATUS feature so the it sees a >>>>>> device supporting LSC. >>>>> That means you are adding a device feature (F_STATUS) and reporting it to >>>>> the driver that this feature is always on, no matter whether the device >>>>> actually supports it or not? This looks wrong to me. >>>> Why? >>> Because you were doing hack to make virtio-user work, while there is no >>> such hack in the QEMU virtio-pci implementation. >>> >>>> IMO, device is not necessary to know this feature. >>> F_STATUS is a device feature. If such feature is not claimed to be >>> supported by the device, the driver should ignore it. But you are >>> unconditionally letting the driver handle it, even though the >>> virito-user device does not claim to support it. >>> >>> Note that F_STATUS is set in the QEMU virtio-net PCI device. >> In QEMU virtio-net PCI device, the device includes QEMU device emulation + >> vhost backend driver. This feature only shows at QEMU device emulation, >> instead of vhost backend driver. This is why we did not see this feature at >> any vhost backends. >> And the embedded virtio-user actually substitutes QEMU device emulation >> part, so this feature should end at this layer. >> >> Let's look this in this way, if we let this feature go through to vhost >> user, it will be treated as an error in vhost_user_set_features(). > Again, why can't we (virtio-user) follow QEMU? Through F2F discussion, I got to know that you treat virtio_user_ethdev.c as front driver part. That makes sense. I'll move this change into vhost-user directory. Thanks, Jianfeng