On Fri, 26 Apr 2024 15:22:02 +0200 Przemek Kitszel wrote: > ## devlink resources (with current API) > `devlink resource` is compelling, partially given the name sounds like a > perfect match. But when we dig just a little bit, the current Path+sizes > (min,max,step) is totally off to what is the most elegant picture of the > situation. In order to fit into existing uAPI, I would need to register > VFs as PF's resource, then GLOBAL LUT and PF LUT as a sub resource to > that (each VF gets two entries under it; plus two additional ones for > PF) I don't like it, I also feel like there is not that much use of > current resources API (it's not natural to use it for distribution, only > for limitation).
Can you share more on how that would look like? From the description it does not sound so bad. Maybe with some CLI / UI changes it will be fine? > ## devlink resources (with extended API) > It is possible to extend current `devlink resource` so instead of only > Path+size, there would be also Path+Owner option to use. > The default state for ice driver would be that PFs owns PF LUTs, GLOBAL > LUTs are all free. > > example proposed flow to assign a GLOBAL LUT to VF0 and PF LUT to VF1: > pf=0000:03:00.0 # likely more meaningful than VSI idx, but open for > vf0=0000:03:00.1 # suggestions > vf1=0000:03:00.2 > devlink resource set pci/$pf path /lut/lut_table_512 owner $pf > devlink resource set pci/$pf path /lut/lut_table_2048 owner free > devlink resource set pci/$pf path /lut/lut_table_512 owner $vf0 > devlink resource set pci/$pf path /lut/lut_table_2048 owner $vf1 Don't we want some level of over-subscription to be allowed?
