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

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Eli Cohen <elic@nvidia.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu
Date: Mon, 16 Aug 2021 16:54:23 -0400	[thread overview]
Message-ID: <20210816165217-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481CF2E07B38C45A2829B7BDCF69@PH0PR12MB5481.namprd12.prod.outlook.com>

On Mon, Aug 09, 2021 at 09:51:49AM +0000, Parav Pandit wrote:
> > From: Michael S. Tsirkin <mst@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?

I'm not sure whether we need both but I'd like to see a full API
and I think we all agree host wants ability to tweak mac after
device creation even if guest is not allowed to change mac, right?

> 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).

I'm inclined to say vxlan is closer to a model to follow.

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization