On 9/15/2022 5:31 PM, Edward Cree wrote:

On 15/09/2022 14:42, Michal Wilczynski wrote:

quoted

Currently devlink-rate only have two types of objects: nodes and leafs.
There is a need to extend this interface to account for a third type of
scheduling elements - queues. In our use case customer is sending
different types of traffic on each queue, which requires an ability to
assign rate parameters to individual queues.

Is there a use-case for this queue scheduling in the absence of a netdevice?
If not, then I don't see how this belongs in devlink; the configuration
  should instead be done in two parts: devlink-rate to schedule between
  different netdevices (e.g. VFs) and tc qdiscs (or some other netdev-level
  API) to schedule different queues within each single netdevice.
Please explain why this existing separation does not support your use-case.

Also I would like to see some documentation as part of this patch.  It looks
  like there's no kernel document for devlink-rate unlike most other devlink
  objects; perhaps you could add one?

-ed

Hi,
Previously we discussed adding queues to devlink-rate in this thread:
https://lore.kernel.org/netdev/20220704114513.2958937-1-michal.wilczynski@intel.com/T/#u (local)
In our use case we are trying to find a way to expose hardware Tx 
scheduler tree that is defined
per port to user. Obviously if the tree is defined per physical port, 
all the scheduling nodes will reside
on the same tree.

Our customer is trying to send different types of traffic that require 
different QoS levels on the same
VM, but on a different queues. This requires completely different rate 
setups for that queue - in the
implementation that you're mentioning we wouldn't be able to arbitrarily 
reassign the queue to any node.
Those queues would still need to share a single parent - their netdev. 
This wouldn't allow us to fully take
advantage of the HQoS and would introduce arbitrary limitations.

Also I would think that since there is only one vendor implementing this 
particular devlink-rate API, there is
some room for flexibility.

Regarding the documentation,  sure. I just wanted to get all the 
feedback from the mailing list and arrive at the final
solution before writing the docs.

BTW, I'm going to be out of office tomorrow, so will respond in this 
thread on Monday.
BR,
Michał