Re: [dpdk-dev] [PATCH 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user

[Cornelia Huck <cohuck@redhat.com>]

On Thu, 13 Feb 2020 10:39:57 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:

> On Thu, 13 Feb 2020 13:41:21 +0100
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Tue, 11 Feb 2020 16:05:51 -0700
> > Alex Williamson <alex.williamson@redhat.com> wrote:

> > > +struct vfio_device_feature {
> > > +	__u32	argsz;
> > > +	__u32	flags;
> > > +#define VFIO_DEVICE_FEATURE_MASK	(0xffff) /* 16-bit feature index */
> > > +#define VFIO_DEVICE_FEATURE_GET		(1 << 16) /* Get feature into data[] */
> > > +#define VFIO_DEVICE_FEATURE_SET		(1 << 17) /* Set feature from data[] */
> > > +#define VFIO_DEVICE_FEATURE_PROBE	(1 << 18) /* Probe feature support */
> > > +	__u8	data[];
> > > +};    
> > 
> > I'm not sure I'm a fan of cramming both feature selection and operation
> > selection into flags. What about:
> > 
> > struct vfio_device_feature {
> > 	__u32 argsz;
> > 	__u32 flags;
> > /* GET/SET/PROBE #defines */
> > 	__u32 feature;
> > 	__u8  data[];
> > };  
> 
> Then data is unaligned so we either need to expand feature or add
> padding.  So this makes the structure at least 8 bytes bigger and buys
> us...?  What's so special about the bottom half of flags that we can't
> designate it as the flags that specify the feature?  We still have
> another 13 bits of flags for future use.

It is more my general dislike of bit fiddling here, no strong
objection, certainly.

> 
> > Getting/setting more than one feature at the same time does not sound
> > like a common use case; you would need to specify some kind of
> > algorithm for that anyway, and just doing it individually seems much
> > easier than that.  
> 
> Yup.  I just figured 2^16 features is a nice way to make use of the
> structure vs 2^32 features and 4 bytes of padding or 2^64 features.  I
> don't think I'm being optimistic in thinking we'll have far less than
> 16K features and we can always reserve feature 0xffff as an extended
> feature where the first 8-bytes of data defines that extended feature
> index.

Agreed, we're probably not going to end up with a flood of features
here.

Anyway, much of this seems to be a matter of personal taste, so let's
keep it as it is.