[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bfd46eb1-bc82-b1c8-f492-7bcaaada8aa4@intel.com>
Date: Fri, 8 Jul 2022 14:16:00 +0800
From: "Zhu, Lingshan" <lingshan.zhu@...el.com>
To: Parav Pandit <parav@...dia.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"mst@...hat.com" <mst@...hat.com>
Cc: "virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"xieyongji@...edance.com" <xieyongji@...edance.com>,
"gautam.dawar@....com" <gautam.dawar@....com>
Subject: Re: [PATCH V3 3/6] vDPA: allow userspace to query features of a vDPA
device
On 7/2/2022 6:02 AM, Parav Pandit wrote:
>
>> From: Zhu Lingshan <lingshan.zhu@...el.com>
>> Sent: Friday, July 1, 2022 9:28 AM
>>
>> This commit adds a new vDPA netlink attribution
>> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES. Userspace can query
>> features of vDPA devices through this new attr.
>>
>> Fixes: a64917bc2e9b vdpa: (Provide interface to read driver feature)
> Missing the "" in the line.
will fix
> I reviewed the patches again.
>
> However, this is not the fix.
> A fix cannot add a new UAPI.
I think we have discussed this, on why we can not re-name the existing
wrong named attr, and why we can not re-use the attr.
So are you suggesting remove this fixes tag?
And why a fix can not add a new uAPI?
>
> Code is already considering negotiated driver features to return the device config space.
> Hence it is fine.
No, the spec says:
The device MUST allow reading of any device-specific configuration
field before FEATURES_OK is set by the driver.
>
> This patch intents to provide device features to user space.
> First what vdpa device are capable of, are already returned by features attribute on the management device.
> This is done in commit [1].
we have discussed this in another thread, vDPA device feature bits can
be different from the management device feature bits.
>
> The only reason to have it is, when one management device indicates that feature is supported, but device may end up not supporting this feature if such feature is shared with other devices on same physical device.
> For example all VFs may not be symmetric after large number of them are in use. In such case features bit of management device can differ (more features) than the vdpa device of this VF.
> Hence, showing on the device is useful.
>
> As mentioned before in V2, commit [1] has wrongly named the attribute to VDPA_ATTR_DEV_SUPPORTED_FEATURES.
> It should have been, VDPA_ATTR_DEV_MGMTDEV_SUPPORTED_FEATURES.
> Because it is in UAPI, and since we don't want to break compilation of iproute2,
> It cannot be renamed anymore.
Yes, rename it will break current uAPI, so I can not rename it.
>
> Given that, we do not want to start trend of naming device attributes with additional _VDPA_ to it as done in this patch.
> Error in commit [1] was exception.
>
> Hence, please reuse VDPA_ATTR_DEV_SUPPORTED_FEATURES to return for device features too.
>
> Secondly, you need output example for showing device features in the commit log.
>
> 3rd, please drop the fixes tag as new capability is not a fix.
>
> [1] cd2629f6df1c ("vdpa: Support reporting max device capabilities ")
>
>> Signed-off-by: Zhu Lingshan <lingshan.zhu@...el.com>
>> ---
>> drivers/vdpa/vdpa.c | 13 +++++++++----
>> include/uapi/linux/vdpa.h | 1 +
>> 2 files changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index
>> ebf2f363fbe7..9b0e39b2f022 100644
>> --- a/drivers/vdpa/vdpa.c
>> +++ b/drivers/vdpa/vdpa.c
>> @@ -815,7 +815,7 @@ static int vdpa_dev_net_mq_config_fill(struct
>> vdpa_device *vdev, static int vdpa_dev_net_config_fill(struct vdpa_device
>> *vdev, struct sk_buff *msg) {
>> struct virtio_net_config config = {};
>> - u64 features;
>> + u64 features_device, features_driver;
>> u16 val_u16;
>>
>> vdpa_get_config_unlocked(vdev, 0, &config, sizeof(config)); @@ -
>> 832,12 +832,17 @@ static int vdpa_dev_net_config_fill(struct vdpa_device
>> *vdev, struct sk_buff *ms
>> if (nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MTU, val_u16))
>> return -EMSGSIZE;
>>
>> - features = vdev->config->get_driver_features(vdev);
>> - if (nla_put_u64_64bit(msg,
>> VDPA_ATTR_DEV_NEGOTIATED_FEATURES, features,
>> + features_driver = vdev->config->get_driver_features(vdev);
>> + if (nla_put_u64_64bit(msg,
>> VDPA_ATTR_DEV_NEGOTIATED_FEATURES, features_driver,
>> + VDPA_ATTR_PAD))
>> + return -EMSGSIZE;
>> +
>> + features_device = vdev->config->get_device_features(vdev);
>> + if (nla_put_u64_64bit(msg,
>> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES,
>> +features_device,
>> VDPA_ATTR_PAD))
>> return -EMSGSIZE;
>>
>> - return vdpa_dev_net_mq_config_fill(vdev, msg, features, &config);
>> + return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver,
>> +&config);
>> }
>>
>> static int
>> diff --git a/include/uapi/linux/vdpa.h b/include/uapi/linux/vdpa.h index
>> 25c55cab3d7c..39f1c3d7c112 100644
>> --- a/include/uapi/linux/vdpa.h
>> +++ b/include/uapi/linux/vdpa.h
>> @@ -47,6 +47,7 @@ enum vdpa_attr {
>> VDPA_ATTR_DEV_NEGOTIATED_FEATURES, /* u64 */
>> VDPA_ATTR_DEV_MGMTDEV_MAX_VQS, /* u32 */
>> VDPA_ATTR_DEV_SUPPORTED_FEATURES, /* u64 */
>> + VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES, /* u64 */
>>
>> VDPA_ATTR_DEV_QUEUE_INDEX, /* u32 */
>> VDPA_ATTR_DEV_VENDOR_ATTR_NAME, /* string */
>> --
>> 2.31.1
Powered by blists - more mailing lists