linux-kernel - Re: Concerns with em.yaml YNL spec

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4bb1ea43-ef52-47ae-8009-6a2944dbf92b@igalia.com>
Date: Sun, 14 Dec 2025 20:35:54 +0900
From: Changwoo Min <changwoo@...lia.com>
To: Andrew Lunn <andrew@...n.ch>, Donald Hunter <donald.hunter@...il.com>
Cc: Lukasz Luba <lukasz.luba@....com>, linux-pm@...r.kernel.org,
 sched-ext@...ts.linux.dev, Jakub Kicinski <kuba@...nel.org>,
 Network Development <netdev@...r.kernel.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Concerns with em.yaml YNL spec



On 12/12/25 02:01, Andrew Lunn wrote:
> On Thu, Dec 11, 2025 at 03:54:53PM +0000, Donald Hunter wrote:
>> Hi,
>>
>> I just spotted the new em.yaml YNL spec that got merged in
>> bd26631ccdfd ("PM: EM: Add em.yaml and autogen files") as part of [1]
>> because it introduced new yamllint reports:
>>
>> make -C tools/net/ynl/ lint
>> make: Entering directory '/home/donaldh/net-next/tools/net/ynl'
>> yamllint ../../../Documentation/netlink/specs
>> ../../../Documentation/netlink/specs/em.yaml
>>    3:1       warning  missing document start "---"  (document-start)
>>    107:13    error    wrong indentation: expected 10 but found 12  (indentation)
>>
>> I guess the patch series was never cced to netdev or the YNL
>> maintainers so this is my first opportunity to review it.
>>
>> Other than the lint messages, there are a few concerns with the
>> content of the spec:
>>
>> - pds, pd and ps might be meaningful to energy model experts but they
>> are pretty meaningless to the rest of us. I see they are spelled out
>> in the energy model header file so it would be better to use
>> perf-domain, perf-table and perf-state here.
> 
> We also need to watch out for other meaning of these letters. In the
> context of networking and Power over Ethernet, PD means Powered
> Device. We generally don't need to enumerate the PD, we are more
> interested in the Power Sourcing Equipment, PSE.
> 
> And a dumb question. What is an energy model? A PSE needs some level
> of energy model, it needs to know how much energy each PD can consume
> in order that it is not oversubscribed.Is the energy model generic
> enough that it could be used for this? Or should this energy model get
> a prefix to limit its scope to a performance domain? The suggested
> name of this file would then become something like
> performance-domain-energy-model.yml?
> 

Lukasz might be the right person for this question. In my view, the
energy model essentially provides the performance-versus-power-
consumption curve for each performance domain.

Conceptually, the energy model covers the system-wide information; a
performance domain is information about one domain (e.g., big/medium/
little CPU blocks), so it is under the energy model; a performance state
is one dot in the performance-versus-power-consumption curve of a
performance domain.

Since the energy model covers the system-wide information, energy-
model.yaml (as Donald suggested) sounds better to me.

Regards,
Changwoo Min