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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <401d70a9-5f6d-ed46-117b-de0b82a5f52c@intel.com>
Date:   Thu, 15 Sep 2022 20:41:52 +0200
From:   "Wilczynski, Michal" <michal.wilczynski@...el.com>
To:     Edward Cree <ecree.xilinx@...il.com>, <netdev@...r.kernel.org>
CC:     <alexandr.lobakin@...el.com>, <dchumak@...dia.com>,
        <maximmi@...dia.com>, <jiri@...nulli.us>,
        <simon.horman@...igine.com>, <jacob.e.keller@...el.com>,
        <jesse.brandeburg@...el.com>, <przemyslaw.kitszel@...el.com>
Subject: Re: [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with
 queues and new parameters

On 9/15/2022 5:31 PM, Edward Cree wrote:
> On 15/09/2022 14:42, Michal Wilczynski wrote:
>> 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
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ł