On 12/10/2019 1:07 PM, Alex Williamson wrote: > On Tue, 10 Dec 2019 03:33:23 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > >>> From: Parav Pandit <parav@xxxxxxxxxxxx> >>> Sent: Saturday, December 7, 2019 1:34 AM >>> >>> On 12/6/2019 2:03 AM, Zhenyu Wang wrote: >>>> On 2019.12.05 18:59:36 +0000, Parav Pandit wrote: >>>>>>> >>>>>>>> On 2019.11.07 20:37:49 +0000, Parav Pandit wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: kvm-owner@xxxxxxxxxxxxxxx <kvm-owner@xxxxxxxxxxxxxxx> >>> On >>>>>>>>>> Behalf Of Zhenyu Wang >>>>>>>>>> Sent: Thursday, October 24, 2019 12:08 AM >>>>>>>>>> To: kvm@xxxxxxxxxxxxxxx >>>>>>>>>> Cc: alex.williamson@xxxxxxxxxx; kwankhede@xxxxxxxxxx; >>>>>>>>>> kevin.tian@xxxxxxxxx; cohuck@xxxxxxxxxx >>>>>>>>>> Subject: [PATCH 0/6] VFIO mdev aggregated resources handling >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This is a refresh for previous send of this series. I got >>>>>>>>>> impression that some SIOV drivers would still deploy their own >>>>>>>>>> create and config method so stopped effort on this. But seems >>>>>>>>>> this would still be useful for some other SIOV driver which may >>>>>>>>>> simply want capability to aggregate resources. So here's refreshed >>>>>> series. >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> Can you please give an example of 'resource'? >>>>>>>>> When I grep [1], [2] and [3], I couldn't find anything related to ' >>>>>> aggregate'. >>>>>>>> >>>>>>>> The resource is vendor device specific, in SIOV spec there's ADI >>>>>>>> (Assignable Device Interface) definition which could be e.g queue >>>>>>>> for net device, context for gpu, etc. I just named this interface as >>>>>> 'aggregate' >>>>>>>> for aggregation purpose, it's not used in spec doc. >>>>>>>> >>>>>>> >>>>>>> Some 'unknown/undefined' vendor specific resource just doesn't work. >>>>>>> Orchestration tool doesn't know which resource and what/how to >>> configure >>>>>> for which vendor. >>>>>>> It has to be well defined. >>>>>>> >>>>>>> You can also find such discussion in recent lgpu DRM cgroup patches >>> series >>>>>> v4. >>>>>>> >>>>>>> Exposing networking resource configuration in non-net namespace >>> aware >>>>>> mdev sysfs at PCI device level is no-go. >>>>>>> Adding per file NET_ADMIN or other checks is not the approach we >>> follow in >>>>>> kernel. >>>>>>> >>>>>>> devlink has been a subsystem though under net, that has very rich >>> interface >>>>>> for syscaller, device health, resource management and many more. >>>>>>> Even though it is used by net driver today, its written for generic device >>>>>> management at bus/device level. >>>>>>> >>>>>>> Yuval has posted patches to manage PCI sub-devices [1] and updated >>> version >>>>>> will be posted soon which addresses comments. > > Always good to see tools that intend to manage arbitrary devices posted > only to the netdev list :-\ > >>>>>>> >>>>>>> For any device slice resource management of mdev, sub-function etc, >>> we >>>>>> should be using single kernel interface as devlink [2], [3]. > > This seems impractical, mdevs and SR-IOV are both enumerated, > inspected, created, and removed in sysfs, Both enumerated via sysfs, but VFs are not configured via sysfs. > where do we define what > features are manipulated vis sysfs versus devlink? VFs are configured via well defined, vendor neutral tool iproute2/ip link set <pf_netdev> vf <vf_index> <attribute> <value> This falls short lately for few cases and non-networking or generic VF property configuration, are proposed to be handled by similar 'VF' object using devlink, because they are either pure 'pci vf' property or more device class type VF property such as MAC address or number_of_queues etc. More advance mode of networking VFs, are controlled using netdev representors again in vendor neutral way for last few years. It may be fair to say that mdev subsystem wants to invent new sysfs files for configuration. mdevs, by > definition, are vendor defined "chunks" of a thing. We allow vendor > drivers to define different types, representing different > configurations of these chunks. Often these different types are > incrementally bigger or smaller chunks of these things, but defining > what bigger and smaller means generically across vendors is an > impossible task. Orchestration tools already need to know vendor > specific information in terms of what type of mdev device they want to > create and make use of. The aggregation seems to simply augment that > vendor information, ie. 'type' and 'scale' are separate rather than > combined only behind just 'type'. > >>>>>>> >>>>>>> [1] >>>>>>> https://lore.kernel.org/netdev/1573229926-30040-1-git-send-email- >>> yuval >>>>>>> av@xxxxxxxxxxxx/ [2] >>>>>>> http://man7.org/linux/man-pages/man8/devlink-dev.8.html >>>>>>> [3] http://man7.org/linux/man-pages/man8/devlink-resource.8.html >>>>>>> >>>>>>> Most modern device configuration that I am aware of is usually done >>> via well >>>>>> defined ioctl() of the subsystem (vhost, virtio, vfio, rdma, nvme and >>> more) or >>>>>> via netlink commands (net, devlink, rdma and more) not via sysfs. >>>>>>> >>>>>> >>>>>> Current vfio/mdev configuration is via documented sysfs ABI instead of >>> other >>>>>> ways. So this adhere to that way to introduce more configurable method >>> on >>>>>> mdev device for standard, it's optional and not actually vendor specific >>> e.g vfio- >>>>>> ap. >>>>>> >>>>> Some unknown/undefined resource as 'aggregate' is just not an ABI. >>>>> It has to be well defined, as 'hardware_address', 'num_netdev_sqs' or >>> something similar appropriate to that mdev device class. >>>>> If user wants to set a parameter for a mdev regardless of vendor, they >>> must have single way to do so. > > Aggregation augments type, which is by definition vendor specific. > >>>> >>>> The idea is not specific for some device class, but for each mdev >>>> type's resource, and be optional for each vendor. If more device class >>>> specific way is preferred, then we might have very different ways for >>>> different vendors. Better to avoid that, so here means to aggregate >>>> number of mdev type's resources for target instance, instead of defining >>>> kinds of mdev types for those number of resources. >>>> >>> Parameter or attribute certainly can be optional. >>> But the way to aggregate them should not be vendor specific. >>> Look for some excellent existing examples across subsystems, for example >>> how you create aggregated netdev or block device is not depend on vendor >>> or underlying device type. >> >> I'd like to hear Alex's opinion on this. Today VFIO mdev supports two styles >> of "types" imo: fixed resource definition (most cases) and dynamic resource >> definition (vfio-ap). In fixed style, a type has fixed association to a set of >> vendor specific resources (resourceX=M, resourceY=N, ...). In dynamic case, >> the user is allowed to specify actual resource X/Y/... backing the mdev >> instance post its creation. In either case, the way to identify such association >> or configurable knobs is vendor specific, maybe contained in optional >> attributes (name and description) plus additional info in vendor documents. >> >> Then the user is assumed to clearly understand the implication of the resource >> allocation under a given type, when creating a new mdev under this type. >> >> If this assumption holds true, the aggregated attribute simply provides an >> extension in the same direction of fixed-style types but allowing for more >> flexible linearly-increasing resource allocation. e.g. when using aggregate=2, >> it means creating a instance with resourceX=2M, resourceY=2N, ... under >> the specified type. Along this direction I didn't see the need of well-defined >> vendor specific attributes here. When those are actually required, I suppose >> the dynamic style would better fit. Or if the vendor driver thinks implementing >> such aggregate feature will confuse its type definition, it's optional to not >> doing so anyway. > > Yep, though I don't think we can even define that aggregate=2 indicates > that every resources is doubled, it's going to have vendor specific > meaning. Maybe this is what Parav is rejecting, but I don't see an > alternative. For example, an mdev vGPU might have high level resources > like the number of execution units, graphics memory, display heads, > maximum resolution, etc. Aggregation could affect one or all of these. > Orchestration tools already need to know the vendor specific type of > device they want to create, so it doesn't seem unreasonable that if > they use aggregation that they choose a type that aggregates the > resource(s) they need, but that aggregation is going to be specific to > the type. Potentially as we think about adding "defined" sysfs > attributes for devices we could start with > $SYSFS_DEV_PATH/mdev/aggregation/type, where value written to type is a > vendor specific aggregation of that mdev type. This allows us the > option that we might someday agree on specific resources that might be > aggregated in a common way (ex. ./aggregation/graphics_memory), but I'm > somewhat doubtful those would ever be pursued. Thanks, > My point is, from Zhenyu Wang's example it is certainly incorrect to define mdev sysfs files, as, vendor_foo_mdev.netdev_mac_addr=X vendor_bar_mdev.resource_addr=Y vendor_foo_mdev.netdev_queues=4 vendor_bar_mdev.aggregate=8 Unless this is a miscellaneous (not well defined) parameter of a vendor device. I am 100% sure that consumers of network devices where a PCI PF is sliced into multiple smaller devices, wants to configure these devices in unified way regardless of vendor type. That may not be the case with vGPU mdevs. If Zhenyu Wang proposed to use networking class of mdev device, attributes should have well defined meaning, as it is well known class in linux kernel. mdev should be providing an API to define such mdev config object and all sysfs for such mdev to be created by the mdev core, not by vendor driver.
