Fri, Feb 21, 2025 at 02:45:12AM +0100, [email protected] wrote: >On Wed, 19 Feb 2025 17:32:54 +0100 Przemek Kitszel wrote: >> Add a support for whole device devlink instance. Intented as a entity >> over all PF devices on given physical device. >> >> In case of ice driver we have multiple PF devices (with their devlink >> dev representation), that have separate drivers loaded. However those >> still do share lots of resources due to being the on same HW. Examples >> include PTP clock and RSS LUT. Historically such stuff was assigned to >> PF0, but that was both not clear and not working well. Now such stuff >> is moved to be covered into struct ice_adapter, there is just one instance >> of such per HW. >> >> This patch adds a devlink instance that corresponds to that ice_adapter, >> to allow arbitrage over resources (as RSS LUT) via it (further in the >> series (RFC NOTE: stripped out so far)). >> >> Thanks to Wojciech Drewek for very nice naming of the devlink instance: >> PF0: pci/0000:00:18.0 >> whole-dev: pci/0000:00:18 >> But I made this a param for now (driver is free to pass just "whole-dev"). > >Which only works nicely if you're talking about functions not full >separate links :) When I was thinking about it a while back my >intuition was that we should have a single instance, just accessible >under multiple names. But I'm not married to that direction if there >are problems with it.
I kind of agree. Like multiple channels to one entity, each labeled by a different name (handle in devlink case). > >> $ devlink dev # (Interesting part of output only) >> pci/0000:af:00: >> nested_devlink: >> pci/0000:af:00.0 >> pci/0000:af:00.1 >> pci/0000:af:00.2 >> pci/0000:af:00.3 >> pci/0000:af:00.4 >> pci/0000:af:00.5 >> pci/0000:af:00.6 >> pci/0000:af:00.7 > >Could you go into more details on what stays on the "nested" instances >and what moves to the "whole-dev"? Jiri recently pointed out to y'all >cases where stuff that should be a port attribute was an instance >attribute.
