On 19/09/2022 14:12, Wilczynski, Michal wrote:

Maybe a switchdev case would be a good parallel here. When you enable switchdev, you get port representors on
the host for each VF that is already attached to the VM. Something that gives the host power to configure
netdev that it doesn't 'own'. So it seems to me like giving user more power to configure things from the host
is acceptable.

Right that's the thing though: I instinctively Want this to be done
 through representors somehow, because it _looks_ like it ought to
 be scoped to a single netdev; but that forces the hierarchy to
 respect netdev boundaries which as we've discussed is an unwelcome
 limitation.

In my mind this is a device-wide configuration, since the ice driver registers each port as a separate pci device.
And each of this devices have their own hardware Tx Scheduler tree global to that port. Queues that we're
discussing are actually hardware queues, and are identified by hardware assigned txq_id.

In general, hardware being a single unit at the device level does
 not necessarily mean its configuration should be device-wide.
For instance, in many NICs each port has a single hardware v-switch,
 but we do not have some kind of "devlink filter" API to program it
 directly.  Instead we attach TC rules to _many_ netdevs, and driver
 code transforms and combines these to program the unitary device.
"device-wide configuration" originally meant things like firmware
 version or operating mode (legacy vs. switchdev) that do not relate
 directly to netdevs.

But I agree with you that your approach is the "least evil method";
 if properly explained and documented then I don't have any
 remaining objection to your patch, despite that I'm continuing to
 take the opportunity to proselytise for "reprs >> devlink" ;)

-ed