Thread (33 messages) 33 messages, 5 authors, 2022-10-11

Re: [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with queues and new parameters

From: Jakub Kicinski <kuba@kernel.org>
Date: 2022-09-22 20:29:52

On Thu, 22 Sep 2022 15:45:55 +0200 Wilczynski, Michal wrote:
On 9/22/2022 2:50 PM, Jakub Kicinski wrote:
quoted
Anyway. My gut feeling is that this is cutting a corner. Seems
most natural for the VF/PF level to be controlled by the admin
and the queue level by whoever owns the queue. The hypervisor
driver/FW should reconcile the two and compile the full hierarchy.  
We tried already tc-htb, and it doesn't work for a couple of reasons, 
even in this potential hybrid with devlink-rate. One of the problems
with tc-htb offload is that it forces you to allocate a new
queue, it doesn't allow for reassigning an existing queue to another 
scheduling node. This is our main use case.

Here's a discussion about tc-htb: 
https://lore.kernel.org/netdev/20220704114513.2958937-1-michal.wilczynski@intel.com/ (local)
This is a problem only for "SR-IOV case" or also for just the PF?
So either I would have to invent a new offload type (?) for tc, or 
completely rewrite and
probably break tc-htb that mellanox implemented.
Also in our use case it's possible to create completely new branches 
from the root and
reassigning queues there. This wouldn't be possible with the method 
you're proposing.

So existing interface doesn't allow us to do what is required.
For some definition of "what is required" which was not really
disclosed clearly. Or I'm to slow to grasp.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help