netdev - Re: [PATCH net-next 0/5][pull request] ice: Support 5 layer Tx scheduler topology

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: <7ece1ba9-03bf-b836-1c55-c57f5235467c@intel.com>
Date: Wed, 24 May 2023 18:59:20 +0200
From: "Wilczynski, Michal" <michal.wilczynski@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Jiri Pirko <jiri@...nulli.us>, Tony Nguyen <anthony.l.nguyen@...el.com>,
	<davem@...emloft.net>, <pabeni@...hat.com>, <edumazet@...gle.com>,
	<netdev@...r.kernel.org>, <lukasz.czapnik@...el.com>,
	<przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH net-next 0/5][pull request] ice: Support 5 layer Tx
 scheduler topology



On 5/24/2023 6:26 PM, Jakub Kicinski wrote:
> On Wed, 24 May 2023 15:25:22 +0200 Wilczynski, Michal wrote:
>>>> For performance reasons there is a need to have support for selectable
>>>> Tx scheduler topology. Currently firmware supports only the default
>>>> 9-layer and 5-layer topology. This patch series enables switch from
>>>> default to 5-layer topology, if user decides to opt-in.  
>>> Why exactly the user cares which FW implementation you use. From what I
>>> see, there is a FW but causing unequal queue distribution in some cases,
>>> you fox this. Why would the user want to alter the behaviour between
>>> fixed and unfixed?  
>> I wouldn't say it's a FW bug. Both approaches - 9-layer and 5-layer
>> have their own pros and cons, and in some cases 5-layer is
>> preferable, especially if the user desires the performance to be
>> better. But at the same time the user gives up the layers in a tree
>> that are actually useful in some cases (especially if using DCB, but
>> also recently added devlink-rate implementation).
> I didn't notice mentions of DCB and devlink-rate in the series.
> The whole thing is really poorly explained.

Sorry about that, I gave examples from the top of my head, since those are the
features that potentially could modify the scheduler tree, seemed obvious to me
at the time. Lowering number of layers in the scheduling tree increases performance,
but only allows you to create a much simpler scheduling tree. I agree that mentioning the
features that actually modify the scheduling tree could be helpful to the reviewer.

Regards,
Michał