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]

Date:   Thu, 15 Sep 2022 22:01:55 +0100
From:   Edward Cree <ecree.xilinx@...il.com>
To:     "Wilczynski, Michal" <michal.wilczynski@...el.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 15/09/2022 19:41, Wilczynski, Michal wrote:
> 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.

I'm not sure I 100% understand what you're describing, but I get the
 impression it's maybe a layering violation — the hypervisor should only
 be responsible for shaping the VM's overall traffic, it should be up to
 the VM to decide how to distribute that bandwidth between traffic types.
But if it's what your customer needs then presumably there's some reason
 for it that I'm not seeing.  I'm not a QoS expert by any means — I just
 get antsy that every time I look at devlink it's gotten bigger and keeps
 escaping further out of the "device-wide configuration" concept it was
 originally sold as :(

> 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.

Oh, so you need a hierarchy within which the VF's queues don't form a
 clade (subtree)?  That sounds like something worth calling out in the
 commit message as the reason why you've designed it this way.

> 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.

Fair.  But you might get better feedback on the code if people have the
 docs to better understand the intent; just a suggestion.

-ed