Virtualization - Aug 2021 - [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu

On Fri, Aug 06, 2021 at 08:55:56AM +0000, Parav Pandit
wrote:
> 
> 
> > From: Michael S. Tsirkin <mst at redhat.com>
> > Sent: Friday, August 6, 2021 2:12 PM
> 
> 
> > >  enum vdpa_attr {
> > > @@ -33,6 +34,16 @@ enum vdpa_attr {
> > >  	VDPA_ATTR_DEV_MAX_VQS,			/* u32 */
> > >  	VDPA_ATTR_DEV_MAX_VQ_SIZE,		/* u16 */
> > > +	VDPA_ATTR_DEV_NET_CFG_MACADDR,		/* binary */
> > > +	VDPA_ATTR_DEV_NET_STATUS,		/* u8 */
> > > +	VDPA_ATTR_DEV_NET_CFG_MAX_VQP,		/* u16 */
> > > +	VDPA_ATTR_DEV_NET_CFG_MTU,		/* u16 */
> > > +	VDPA_ATTR_DEV_NET_CFG_SPEED,		/* u16 */
> > > +	VDPA_ATTR_DEV_NET_CFG_DUPLEX,		/* u16 */
> > > +	VDPA_ATTR_DEV_NET_CFG_RSS_MAX_KEY_LEN,	/* u8 */
> > > +	VDPA_ATTR_DEV_NET_CFG_RSS_MAX_IT_LEN,	/* u16 */
> > > +	VDPA_ATTR_DEV_NET_CFG_RSS_HASH_TYPES,	/* u32 */
> > > +
> > >  	/* new attributes must be added above here */
> > >  	VDPA_ATTR_MAX,
> > >  };
> > 
> > The point is to try and not reinvent a dedicated vpda interface where
a
> > generic one exits.
> > E.g. for phy things such as mac speed etc, I think most people are
using
> > ethtool things right?
> 
> As you know vdpa is the backend device for the front-end netdevice accessed
by the ethtool.
> vdpa management tool here is composing the vdpa device.
> 
> For example creator (hypervisor) of the vdpa devices knows that a guest VM
is given 4 vcpus,
> So hypervisor creates a vdpa devices with config space layout as,
> max_virtqueue_pairs = 4.
> And the MAC address chosen by hypervisor in mac[6].
> 
> Guest VM ethtool can still chose to use less number of channels.
> 
> Typically,
> ethtool is for guest VM.
> vdpa device is in hypevisor.
> 
> How can hypervisor compose a vdpa device without any tool?
> How can it tell ethtool, what is supported and what are the defaults?
> 
> I must be misunderstanding your comment about ethtool.
> Can you please explain?

I am basically saying that we probably want to be able to
change MAC of a VDPA device on the host without desroying and recreating the
device
as long as it's not in use.

For a VF I can do this on the host:

ip link set eth0 vf 1 mac 00:11:22:33:44:55

ideally same thing would work for vdpa.

-- 
MST

> From: Michael S. Tsirkin <mst at redhat.com>
> Sent: Monday, August 9, 2021 3:10 PM
> 
> On Fri, Aug 06, 2021 at 08:55:56AM +0000, Parav Pandit wrote:
> >
> >
> > >
> > > The point is to try and not reinvent a dedicated vpda interface
> > > where a generic one exits.
> > > E.g. for phy things such as mac speed etc, I think most people
are
> > > using ethtool things right?
> >
> > As you know vdpa is the backend device for the front-end netdevice
> accessed by the ethtool.
> > vdpa management tool here is composing the vdpa device.
> >
> > For example creator (hypervisor) of the vdpa devices knows that a
> > guest VM is given 4 vcpus, So hypervisor creates a vdpa devices with
> > config space layout as, max_virtqueue_pairs = 4.
> > And the MAC address chosen by hypervisor in mac[6].
> >
> > Guest VM ethtool can still chose to use less number of channels.
> >
> > Typically,
> > ethtool is for guest VM.
> > vdpa device is in hypevisor.
> >
> > How can hypervisor compose a vdpa device without any tool?
> > How can it tell ethtool, what is supported and what are the defaults?
> >
> > I must be misunderstanding your comment about ethtool.
> > Can you please explain?
> 
> 
> I am basically saying that we probably want to be able to change MAC of a
> VDPA device on the host without desroying and recreating the device as long
> as it's not in use.
Ok. I understood your comment now.
Yes, this was the objective which is why they are present as independent config
knob.
Jason was suggesting to have them as creation only knobs, which requires
recreate.

I don't have strong opinion for either method.

Passing them at creation time is simpler for user.
If user needs the ability to modify and reuse same device with different config,
extending such support in future like this patch should possible.

So there are two questions to close.
1. Can we start with config params at vdpa device creation time?

2. Is it ok to have these config params as individual fields at netlink U->K
UAPI level?
This is the method proposed in this patch series.
(Similar to incrementally growing vxlan ip link command).

Or 
They should be packed in a structure between U-> K and deal with typecasting
based on size and more?
(Jason's input).