Re: [libvirt] [PATCH v2 0/4] New mdev type handling for aggregated resources
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(a)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