On Tue, Aug 25, 2020 at 04:39:25PM +0200, Cornelia Huck wrote: <...>
do you think the bin_attribute I proposed yesterday good? Then we can have a single compatible with a variable in the mdev_type and aggregator.
mdev_type=i915-GVTg_V5_{val1:int:2,4,8} aggregator={val1}/2
I'm not really a fan of binary attributes other than in cases where we have some kind of binary format to begin with.
IIUC, we basically have: - different partitioning (expressed in the mdev_type) - different number of partitions (expressed via the aggregator) - devices being compatible if the partitioning:aggregator ratio is the same
(The multiple mdev_type variants seem to come from avoiding extra creation parameters, IIRC?)
Would it be enough to export base_type=i915-GVTg_V5 aggregation_ratio=<integer>
to express the various combinations that are compatible without the need for multiple sets of attributes?
yes. I agree we need to decouple the mdev type name and aggregator for compatibility detection purpose. please allow me to put some words to describe the history and motivation of introducing aggregator. initially, we have fixed mdev_type i915-GVTg_V5_1, i915-GVTg_V5_2, i915-GVTg_V5_4, i915-GVTg_V5_8, the digital after i915-GVTg_V5 representing the max number of instances allowed to be created for this type. They also identify how many resources are to be allocated for each type. They are so far so good for current intel vgpus, i.e., cutting the physical GPU into several virtual pieces and sharing them among several VMs in pure mediation way. fixed types are provided in advance as we thought it can meet needs from most users and users can know the hardware capability they acquired from the type name. the bigger in number, the smaller piece of physical hardware. Then, when it comes to scalable IOV in near future, one physical hardware is able to be cut into a large number of units in hardware layer The single unit to be assigned into guest can be very small while one to several units are grouped into an mdev. The fixed type scheme is then cumbersome. Therefore, a new attribute aggregator is introduced to specify the number of resources to be assigned based on the base resource specified in type name. e.g. if type name is dsa-1dwq, and aggregator is 30, then the assignable resources to guest is 30 wqs in a single created mdev. if type name is dsa-2dwq, and aggregator is 15, then the assignable resources to guest is also 30wqs in a single created mdev. (in this example, the rule to define type name is different to the case in GVT. here 1 wq means wq number is 1. yes, they are current reality. :) ) previously, we want to regard the two mdevs created with dsa-1dwq x 30 and dsa-2dwq x 15 as compatible, because the two mdevs consist equal resources. But, as it's a burden to upper layer, we agree that if this condition happens, we still treat the two as incompatible. To fix it, either the driver should expose dsa-1dwq only, or the target dsa-2dwq needs to be destroyed and reallocated via dsa-1dwq x 30. Does it make sense? Thanks Yan