From mboxrd@z Thu Jan  1 00:00:00 1970
From: Erik Skultety <eskultet@redhat.com>
Subject: Re: [libvirt] [PATCH v2 0/4] New mdev type handling for aggregated
 resources
Date: Thu, 26 Jul 2018 15:50:28 +0200
Message-ID: <20180726135028.GG11030@beluga.usersys.redhat.com>
References: <20180620074039.10539-1-zhenyuw@linux.intel.com>
	<20180720021928.15343-1-zhenyuw@linux.intel.com>
	<20180724114440.76564e75@t450s.home>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kevin.tian@intel.com, kvm@vger.kernel.org, libvirt-list@redhat.com,
	Zhenyu Wang <zhenyuw@linux.intel.com>, kwankhede@nvidia.com,
	intel-gvt-dev@lists.freedesktop.org
To: Alex Williamson <alex.williamson@redhat.com>
Return-path: <libvir-list-bounces@redhat.com>
Content-Disposition: inline
In-Reply-To: <20180724114440.76564e75@t450s.home>
List-Unsubscribe: <https://www.redhat.com/mailman/options/libvir-list>,
	<mailto:libvir-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/libvir-list>
List-Post: <mailto:libvir-list@redhat.com>
List-Help: <mailto:libvir-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/libvir-list>,
	<mailto:libvir-list-request@redhat.com?subject=subscribe>
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
List-Id: kvm.vger.kernel.org

On Tue, Jul 24, 2018 at 11:44:40AM -0600, Alex Williamson wrote:
> On Fri, 20 Jul 2018 10:19:24 +0800
> Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
>
> > Current mdev device create interface depends on fixed mdev type, which get uuid
> > from user to create instance of mdev device. If user wants to use customized
> > number of resource for mdev device, then only can create new mdev type for that
> > which may not be flexible. This requirement comes not only from to be able to
> > allocate flexible resources for KVMGT, but also from Intel scalable IO
> > virtualization which would use vfio/mdev to be able to allocate arbitrary
> > resources on mdev instance. More info on [1] [2] [3].
> >
> > To allow to create user defined resources for mdev, it trys to extend mdev
> > create interface by adding new "instances=xxx" parameter following uuid, for
> > target mdev type if aggregation is supported, it can create new mdev device
> > which contains resources combined by number of instances, e.g
> >
> >     echo "<uuid>,instances=10" > create
> >
> > VM manager e.g libvirt can check mdev type with "aggregation" attribute which
> > can support this setting. If no "aggregation" attribute found for mdev type,
> > previous behavior is still kept for one instance allocation. And new sysfs
> > attribute "instances" is created for each mdev device to show allocated number.
> >
> > This trys to create new KVMGT type with minimal vGPU resources which can be
> > combined with "instances=x" setting to allocate for user wanted resources.
>
> "instances" makes me think this is arg helps to create multiple mdev
> instances rather than consuming multiple instances for a single mdev.
> You're already exposing the "aggregation" attribute, so doesn't
> "aggregate" perhaps make more sense as the create option?  We're asking
> the driver to aggregate $NUM instances into a single mdev.  The mdev
> attribute should then perhaps also be "aggregated_instances".
>
> The next user question for the interface might be what aspect of the
> device gets multiplied by this aggregation?  In i915 I see you're
> multiplying the memory sizes by the instance, but clearly the
> resolution doesn't change.  I assume this is sort of like mdev types
> themselves, ie. some degree of what a type means is buried in the
> implementation and some degree of what some number of those types
> aggregated together means is impossible to describe generically.

I don't seem to clearly see the benefit here, so I have to ask, how is this
better and/or different from allowing a heterogeneous setup if one needs a more
performant instance in terms of more resources? Because to me, once you're able
to aggregate instances, I would assume that a simple "echo `uuid`" with a
different type should succeed as well and provide me (from user's perspective)
with the same results. Could you please clarify this to me, as well as what
resources/parameters are going to be impacted by aggregation?

...

>
> I'm curious what libvirt folks and Kirti think of this, it looks like
> it has a nice degree of backwards compatibility, both in the sysfs
> interface and the vendor driver interface.  Thanks,

Since libvirt doesn't have an API to create mdevs yet, this doesn't pose an
issue for us at the moment. I see this adds new optional sysfs attributes which
we could expose within our device capabilities XML, provided it doesn't use a
free form text, like the description attribute does.

Erik