> From: Jason Wang <jasowang@xxxxxxxxxx>
> Sent: Wednesday, April 7, 2021 9:26 AM
[..]
> > /**
> > * struct vdpa_config_ops - operations for configuring a vDPA device.
> > * Note: vDPA device drivers are required to implement all of the @@
> > -164,6 +200,10 @@ struct vdpa_iova_range {
> > * @buf: buffer used to write from
> > * @len: the length to write to
> > * configuration space
> > + * @get_ce_config: Read device specific configuration in
> > + * cpu endianness.
> > + * @vdev: vdpa device
> > + * @config: pointer to config buffer used to
> read to
>
>
> So I wonder what's the reason for having this? If it's only the reason of
> endian, we can just use get_config.
>
Didn't follow your suggestion.
How does in kernel management tool caller get_config know how to do endianenss conversion?
Or you are proposing to send this whole virtio_config structure as binary data to user space via netlink?
If so, it is not a practice in netlink to return struct.
Also making netlink user space to understand __virtio16 doesn't sound correct.
Often orchestration is not written in C. I cannot think of returning virtio_net_config via netlink socket if it is your thought.
And decoding it requires to query features too. Querying features and config are not atomic so parsed value can be wrong.
Endianness has to be self-contained in fields return via netlink. With that baseline, lets think further.
> We don't plan to expose a legacy or transition device, so we can simply do
> the endian conversion in the device.
>
I am bit confused with Michael's suggestion in v1 [1].
VIRTIO_F_VERSION_1 is set today by mlx5 and ifcvf driver.
> Then we can stick to the uapi of virtio_net_config and there's no need for the
> VDPA_ATTR_DEV_NET_CFG_XXX?
>
[1] https://lore.kernel.org/virtualization/20210224020336-mutt-send-email-mst@xxxxxxxxxx/
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
