From: "lihuisong (C)" <lihuisong@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>, dev@dpdk.org
Cc: <thomas@monjalon.net>, <ferruh.yigit@amd.com>,
<anatoly.burakov@intel.com>, <david.hunt@intel.com>,
<sivaprasad.tummala@amd.com>, <liuyonglong@huawei.com>
Subject: Re: [PATCH 0/2] introduce PM QoS interface
Date: Thu, 21 Mar 2024 11:04:09 +0800 [thread overview]
Message-ID: <9d896d8e-e624-6501-5c2d-d6b664c9a15d@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F315@smartserver.smartshare.dk>
Hi Moren,
Thanks for your revew.
在 2024/3/20 22:05, Morten Brørup 写道:
>> From: Huisong Li [mailto:lihuisong@huawei.com]
>> Sent: Wednesday, 20 March 2024 11.55
>>
>> The system-wide CPU latency QoS limit has a positive impact on the idle
>> state selection in cpuidle governor.
>>
>> Linux creates a cpu_dma_latency device under '/dev' directory to obtain the
>> CPU latency QoS limit on system and send the QoS request for userspace.
>> Please see the PM QoS framework in the following link:
>> https://docs.kernel.org/power/pm_qos_interface.html?highlight=qos
>> This feature is supported by kernel-v2.6.25.
>>
>> The deeper the idle state, the lower the power consumption, but the longer
>> the resume time. Some service are delay sensitive and very except the low
>> resume time, like interrupt packet receiving mode.
>>
>> So this series introduce PM QoS interface.
> This looks like a 1:1 wrapper for a Linux kernel feature.
right
> Does Windows or BSD offer something similar?
How do we know Windows or BSD support this similar feature?
The DPDK power lib just work on Linux according to the meson.build under
lib/power.
If they support this features, they can open it.
>
> Furthermore, any high-res timing should use nanoseconds, not microseconds or milliseconds.
> I realize that the Linux kernel only uses microseconds for these APIs, but the DPDK API should use nanoseconds.
Nanoseconds is more precise, it's good.
But DPDK API how use nanoseconds as you said the the Linux kernel only
uses microseconds for these APIs.
Kernel interface just know an integer value with microseconds unit.
/BR
/Huisong
next prev parent reply other threads:[~2024-03-21 3:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 10:55 Huisong Li
2024-03-20 10:55 ` [PATCH 1/2] power: " Huisong Li
2024-03-20 10:55 ` [PATCH 2/2] examples/l3fwd-power: add PM QoS request configuration Huisong Li
2024-03-20 14:05 ` [PATCH 0/2] introduce PM QoS interface Morten Brørup
2024-03-21 3:04 ` lihuisong (C) [this message]
2024-03-21 13:30 ` Morten Brørup
2024-03-22 8:54 ` lihuisong (C)
2024-03-22 12:35 ` Morten Brørup
2024-03-26 2:11 ` lihuisong (C)
2024-03-26 8:27 ` Morten Brørup
2024-03-26 12:15 ` lihuisong (C)
2024-03-26 12:46 ` Morten Brørup
2024-03-29 1:59 ` lihuisong (C)
2024-03-22 17:55 ` Tyler Retzlaff
2024-03-26 2:20 ` lihuisong (C)
2024-03-26 16:04 ` Tyler Retzlaff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9d896d8e-e624-6501-5c2d-d6b664c9a15d@huawei.com \
--to=lihuisong@huawei.com \
--cc=anatoly.burakov@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=liuyonglong@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=sivaprasad.tummala@amd.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).