From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D14A445B5C; Thu, 17 Oct 2024 10:38:03 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 60C1840279; Thu, 17 Oct 2024 10:38:03 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 4D37740273 for ; Thu, 17 Oct 2024 10:38:02 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4XTh5H0VDvzyT8T; Thu, 17 Oct 2024 16:36:35 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id ED6BD1401F4; Thu, 17 Oct 2024 16:37:59 +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.39; Thu, 17 Oct 2024 16:37:59 +0800 Message-ID: Date: Thu, 17 Oct 2024 16:37:58 +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 v10 1/2] power: introduce PM QoS API on CPU wide To: Stephen Hemminger CC: , , , , , , , , , , "konstantin.ananyev@huawei.com" References: <20240320105529.5626-1-lihuisong@huawei.com> <20240912023812.30885-1-lihuisong@huawei.com> <20240912023812.30885-2-lihuisong@huawei.com> <20241012181030.60d7647a@hermes.local> <39734c23-0f65-1bae-bb4e-2c6bf06aa97c@huawei.com> <20241015084555.3f9f7669@hermes.local> <87ebf2dd-dc08-c32c-5a30-c6712a62b9b6@huawei.com> <20241016202016.14182322@hermes.local> From: "lihuisong (C)" In-Reply-To: <20241016202016.14182322@hermes.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 在 2024/10/17 11:20, Stephen Hemminger 写道: > On Thu, 17 Oct 2024 10:11:13 +0800 > "lihuisong (C)" wrote: > >> Hi Stephen, >> >> 在 2024/10/15 23:45, Stephen Hemminger 写道: >>> On Tue, 15 Oct 2024 17:41:39 +0800 >>> "lihuisong (C)" wrote: >>> >>>> Hi Stephen, >>>> >>>> Can you take a look at this reply so as to send out the next version ASAP? >>>> Thanks.😁 >>>> >>>> /Huisong >>>> 在 2024/10/14 20:19, lihuisong (C) 写道: >>> The biggest issue is that lcore is not the same as cpu as far as kernel is concerned. >>> DPDK support mapping lcore to a cpuset, and that is not necessarily the same one-to-one mapping >>> as values in sysfs. In documentation of eal see. >> Yes, you are right. >>> For example, "--lcores='1,2@(5-7),(3-5)@(0,2),(0,6),7-8'" which means start 9 EAL thread; >>> lcore 0 runs on cpuset 0x41 (cpu 0,6); >>> lcore 1 runs on cpuset 0x2 (cpu 1); >>> lcore 2 runs on cpuset 0xe0 (cpu 5,6,7); >>> lcore 3,4,5 runs on cpuset 0x5 (cpu 0,2); >>> lcore 6 runs on cpuset 0x41 (cpu 0,6); >>> lcore 7 runs on cpuset 0x80 (cpu 7); >>> lcore 8 runs on cpuset 0x100 (cpu 8). >>> >>> This problem existed in power library and this new API still has it. >> How about use lcore_config[lcore_id].cpuset to get the real cpu_id? >> And for this case that application use '--lcores', we simply do some >> operations in power lib for all mapping CPUs in lcore's cpuset. >> If it is ok, I will fix it for the entire power library and this new API. > Using the lcore_config is the right direction but the cpuset may have more than > one cpu, so the code needs to iterate over those cpus. Probably safe to ignore problems > the case where user misconfigures to have two lcores using an overlapping set of cpu's > like the example in the doc. > . Yes, so we don't care this overlapping set case. That's attributed to an usage issue and we just need to clearly comment this case's influence in doc, ok?