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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists