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: <9656fcda-0d63-06dc-0803-bc5f90ee44fd@intel.com>
Date:   Thu, 22 Sep 2022 15:45:55 +0200
From:   "Wilczynski, Michal" <michal.wilczynski@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Edward Cree <ecree.xilinx@...il.com>, <netdev@...r.kernel.org>,
        <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/22/2022 2:50 PM, Jakub Kicinski wrote:
> On Thu, 22 Sep 2022 13:44:14 +0200 Wilczynski, Michal wrote:
>> Below I'll paste the output of how initially the topology looks like for our
>> hardware.
>> If the devlink_port objects are present (as in switchdev mode), there
>> should also be vport nodes represented. It is NOT a requirement for
>> a queue to have a vport as it's ancestor.
> Thanks! How did you know that my preferred method of reading
> hierarchies is looking at a linear output!? 😕

Haha :D, sorry about that, that's the real output from the devlink tool 
that I
modified, so it's already like that for devlink-rate. At least I don't 
know about
any way to represent this better, besides drawing the hierarchy by hand. And
it's quite big of a hierarchy.

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

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.

BR,
Michał


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ