Virtualization - Jun 2021 - [PATCH linux-next v3 2/6] vdpa: Introduce query of device config layout

? 2021/6/22 ??10:03, Parav Pandit ??:
>> Is it better to use a separate enum for net specific attributes?
>>
> Yes, because they are only net specific.
> I guess it is related to your below question.
>
>> Another question (sorry if it has been asked before). Can we simply
>> return the config (binary) to the userspace, then usespace can use the
>> existing uAPI like virtio_net_config plus the feature to explain the
config?
>>
> We did discuss in v2.
> Usually returning the whole blob and parsing is not desired via netlink.
> Returning individual fields give the full flexibility to return only the
valid fields.
> Otherwise we need to implement another bitmask too to tell which fields
from the struct are valid and share with user space.
> Returning individual fields is the widely used approach.

The main concerns are:

1) The blob will be self contained if it was passed with the negotiated 
features, so we don't need bitmask.
2) Using individual fields means it must duplicate the config fields of 
every virtio devices

And actually, it's not the binary blob since uapi clearly define the 
format (e.g struct virtio_net_config), can we find a way to use that?? 
E.g introduce device/net specific command and passing the blob with 
length and negotiated features.

Thanks

>

> From: Jason Wang <jasowang at redhat.com>
> Sent: Wednesday, June 23, 2021 9:39 AM
> 
> ? 2021/6/22 ??10:03, Parav Pandit ??:
> >> Is it better to use a separate enum for net specific attributes?
> >>
> > Yes, because they are only net specific.
> > I guess it is related to your below question.
> >
> >> Another question (sorry if it has been asked before). Can we
simply
> >> return the config (binary) to the userspace, then usespace can use
> >> the existing uAPI like virtio_net_config plus the feature to
explain the
> config?
> >>
> > We did discuss in v2.
> > Usually returning the whole blob and parsing is not desired via
netlink.
> > Returning individual fields give the full flexibility to return only
the valid
> fields.
> > Otherwise we need to implement another bitmask too to tell which
fields
> from the struct are valid and share with user space.
> > Returning individual fields is the widely used approach.
> 
> 
> The main concerns are:
> 
> 1) The blob will be self contained if it was passed with the negotiated
> features, so we don't need bitmask.
Which fields of the struct are valid is told by additional
fields.
> 2) Using individual fields means it must duplicate the config fields of
every
> virtio devices
> 
Mostly no. if there are common config fields across two device types, they would
be named as
VDPA_ATTR_DEV_CFG_*
Net specific will be,
VDPA_ATTR_DEV_NET_CFG_*
Block specific, will be,
VDPA_ATTR_DEV_BLK_CFG_*
> And actually, it's not the binary blob since uapi clearly define the
format (e.g
> struct virtio_net_config), can we find a way to use that? E.g introduce
> device/net specific command and passing the blob with length and
> negotiated features.
Length may change in future, mostly expand. And parsing based on length is not
such a clean way.
Parsing fields require knowledge of features as well and application needs to
make multiple netlink calls to parse the config space.
I prefer to follow rest of the kernel style to return self contained
invidividual fields.