From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 9933743D0D;
	Thu, 21 Mar 2024 04:04:16 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 85F45402DA;
	Thu, 21 Mar 2024 04:04:16 +0100 (CET)
Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35])
 by mails.dpdk.org (Postfix) with ESMTP id DD8994028B
 for <dev@dpdk.org>; Thu, 21 Mar 2024 04:04:14 +0100 (CET)
Received: from mail.maildlp.com (unknown [172.19.88.234])
 by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4V0Vbh3053z1R7Pj;
 Thu, 21 Mar 2024 11:01:36 +0800 (CST)
Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242])
 by mail.maildlp.com (Postfix) with ESMTPS id BCDB11400CA;
 Thu, 21 Mar 2024 11:04:10 +0800 (CST)
Received: from [10.67.121.59] (10.67.121.59) by kwepemm600004.china.huawei.com
 (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 21 Mar
 2024 11:04:10 +0800
Message-ID: <9d896d8e-e624-6501-5c2d-d6b664c9a15d@huawei.com>
Date: Thu, 21 Mar 2024 11:04:09 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCH 0/2] introduce PM QoS interface
To: =?UTF-8?Q?Morten_Br=c3=b8rup?= <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>
References: <20240320105529.5626-1-lihuisong@huawei.com>
 <98CBD80474FA8B44BF855DF32C47DC35E9F315@smartserver.smartshare.dk>
From: "lihuisong (C)" <lihuisong@huawei.com>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F315@smartserver.smartshare.dk>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.67.121.59]
X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To
 kwepemm600004.china.huawei.com (7.193.23.242)
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

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