On Thu, 20 Aug 2020 11:16:21 +0800 Yan Zhao <yan.y.zhao@intel.com> wrote:
On Wed, Aug 19, 2020 at 09:22:34PM -0600, Alex Williamson wrote:
On Thu, 20 Aug 2020 08:39:22 +0800 Yan Zhao <yan.y.zhao@intel.com> wrote:
On Tue, Aug 18, 2020 at 11:36:52AM +0200, Cornelia Huck wrote:
On Tue, 18 Aug 2020 10:16:28 +0100 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Aug 18, 2020 at 05:01:51PM +0800, Jason Wang wrote:
On 2020/8/18 下午4:55, Daniel P. Berrangé wrote:
On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote:
On 2020/8/14 下午1:16, Yan Zhao wrote:
On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote:
On 2020/8/10 下午3:46, Yan Zhao wrote:
we actually can also retrieve the same information through sysfs, .e.g
|- [path to device] |--- migration | |--- self | | |---device_api | | |---mdev_type | | |---software_version | | |---device_id | | |---aggregator | |--- compatible | | |---device_api | | |---mdev_type | | |---software_version | | |---device_id | | |---aggregator
Yes but:
- You need one file per attribute (one syscall for one attribute) - Attribute is coupled with kobject
Is that really that bad? You have the device with an embedded kobject anyway, and you can just put things into an attribute group?
[Also, I think that self/compatible split in the example makes things needlessly complex. Shouldn't semantic versioning and matching already cover nearly everything? I would expect very few cases that are more complex than that. Maybe the aggregation stuff, but I don't think we need that self/compatible split for that, either.] Hi Cornelia,
The reason I want to declare compatible list of attributes is that sometimes it's not a simple 1:1 matching of source attributes and target attributes as I demonstrated below, source mdev of (mdev_type i915-GVTg_V5_2 + aggregator 1) is compatible to target mdev of (mdev_type i915-GVTg_V5_4 + aggregator 2), (mdev_type i915-GVTg_V5_8 + aggregator 4)
and aggragator may be just one of such examples that 1:1 matching does not fit.
If you're suggesting that we need a new 'compatible' set for every aggregation, haven't we lost the purpose of aggregation? For example, rather than having N mdev types to represent all the possible aggregation values, we have a single mdev type with N compatible migration entries, one for each possible aggregation value. BTW, how do we have multiple compatible directories? compatible0001, compatible0002? Thanks,
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?