dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
From: "lihuisong (C)" <lihuisong@huawei.com>
To: "Tummala, Sivaprasad" <Sivaprasad.Tummala@amd.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"david.hunt@intel.com" <david.hunt@intel.com>,
	"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
	"radu.nicolau@intel.com" <radu.nicolau@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"cristian.dumitrescu@intel.com" <cristian.dumitrescu@intel.com>,
	"konstantin.ananyev@huawei.com" <konstantin.ananyev@huawei.com>,
	"Yigit, Ferruh" <Ferruh.Yigit@amd.com>,
	"gakhil@marvell.com" <gakhil@marvell.com>
Subject: Re: [PATCH v2 2/4] power: refactor uncore power management library
Date: Tue, 22 Oct 2024 10:05:36 +0800	[thread overview]
Message-ID: <d339c98e-d1b7-1b66-5376-6f84aa94e705@huawei.com> (raw)
In-Reply-To: <CH3PR12MB8233830FC963B0F43FD4A4F4867E2@CH3PR12MB8233.namprd12.prod.outlook.com>

Hi Sivaprasa,

I have a inline question, please take a look.

在 2024/10/8 14:19, Tummala, Sivaprasad 写道:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Lihuisong,
>
>> -----Original Message-----
>> From: lihuisong (C) <lihuisong@huawei.com>
>> Sent: Tuesday, August 27, 2024 6:33 PM
>> To: Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>
>> Cc: dev@dpdk.org; david.hunt@intel.com; anatoly.burakov@intel.com;
>> radu.nicolau@intel.com; jerinj@marvell.com; cristian.dumitrescu@intel.com;
>> konstantin.ananyev@huawei.com; Yigit, Ferruh <Ferruh.Yigit@amd.com>;
>> gakhil@marvell.com
>> Subject: Re: [PATCH v2 2/4] power: refactor uncore power management library
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> Hi Sivaprasad,
>>
>> Suggest to split this patch into two patches for easiler to review:
>> patch-1: abstract a file for uncore dvfs core level, namely, the
>> rte_power_uncore_ops.c you did.
>> patch-2: move and rename, lib/power/power_intel_uncore.c =>
>> drivers/power/intel_uncore/intel_uncore.c
>>
>> patch[1/4] is also too big and not good to review.
>>
>> In addition, I have some question and am not sure if we can adjust uncore init
>> process.
>>
>> /Huisong
>>
>>
>> 在 2024/8/26 21:06, Sivaprasad Tummala 写道:
>>> This patch refactors the power management library, addressing uncore
>>> power management. The primary changes involve the creation of
>>> dedicated directories for each driver within 'drivers/power/uncore/*'.
>>> The adjustment of meson.build files enables the selective activation
>>> of individual drivers.
>>>
>>> This refactor significantly improves code organization, enhances
>>> clarity and boosts maintainability. It lays the foundation for more
>>> focused development on individual drivers and facilitates seamless
>>> integration of future enhancements, particularly the AMD uncore driver.
>>>
>>> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
>>> ---
>>>    .../power/intel_uncore/intel_uncore.c         |  18 +-
>>>    .../power/intel_uncore/intel_uncore.h         |   8 +-
>>>    drivers/power/intel_uncore/meson.build        |   6 +
>>>    drivers/power/meson.build                     |   3 +-
>>>    lib/power/meson.build                         |   2 +-
>>>    lib/power/rte_power_uncore.c                  | 205 ++++++---------
>>>    lib/power/rte_power_uncore.h                  |  87 ++++---
>>>    lib/power/rte_power_uncore_ops.h              | 239 ++++++++++++++++++
>>>    lib/power/version.map                         |   1 +
>>>    9 files changed, 405 insertions(+), 164 deletions(-)
>>>    rename lib/power/power_intel_uncore.c =>
>> drivers/power/intel_uncore/intel_uncore.c (95%)
>>>    rename lib/power/power_intel_uncore.h =>
>> drivers/power/intel_uncore/intel_uncore.h (97%)
>>>    create mode 100644 drivers/power/intel_uncore/meson.build
>>>    create mode 100644 lib/power/rte_power_uncore_ops.h
>>>
>>> diff --git a/lib/power/power_intel_uncore.c
>>> b/drivers/power/intel_uncore/intel_uncore.c
>>> similarity index 95%
>>> rename from lib/power/power_intel_uncore.c rename to
>>> drivers/power/intel_uncore/intel_uncore.c
>>> index 4eb9c5900a..804ad5d755 100644
>>> --- a/lib/power/power_intel_uncore.c
>>> +++ b/drivers/power/intel_uncore/intel_uncore.c
>>> @@ -8,7 +8,7 @@
>>>
>>>    #include <rte_memcpy.h>
>>>
>>> -#include "power_intel_uncore.h"
>>> +#include "intel_uncore.h"
>>>    #include "power_common.h"
>>>
>>>    #define MAX_NUMA_DIE 8
>>> @@ -475,3 +475,19 @@ power_intel_uncore_get_num_dies(unsigned int pkg)
>>>
>>>        return count;
>>>    }
>> <...>
>>> -#endif /* POWER_INTEL_UNCORE_H */
>>> +#endif /* INTEL_UNCORE_H */
>>> diff --git a/drivers/power/intel_uncore/meson.build
>>> b/drivers/power/intel_uncore/meson.build
>>> new file mode 100644
>>> index 0000000000..876df8ad14
>>> --- /dev/null
>>> +++ b/drivers/power/intel_uncore/meson.build
>>> @@ -0,0 +1,6 @@
>>> +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017 Intel
>>> +Corporation # Copyright(c) 2024 Advanced Micro Devices, Inc.
>>> +
>>> +sources = files('intel_uncore.c')
>>> +deps += ['power']
>>> diff --git a/drivers/power/meson.build b/drivers/power/meson.build
>>> index 8c7215c639..c83047af94 100644
>>> --- a/drivers/power/meson.build
>>> +++ b/drivers/power/meson.build
>>> @@ -6,7 +6,8 @@ drivers = [
>>>            'amd_pstate',
>>>            'cppc',
>>>            'kvm_vm',
>>> -        'pstate'
>>> +        'pstate',
>>> +        'intel_uncore'
>> The cppc, amd_pstate and so on belong to cpufreq scope.
>> And intel_uncore belongs to uncore dvfs scope.
>> They are not the same level. So I proposes that we need to create one directory
>> called like cpufreq or core.
>> This 'intel_uncore' name don't seems appropriate. what do you think the following
>> directory structure:
>> drivers/power/uncore/intel_uncore.c
>> drivers/power/uncore/amd_uncore.c (according to the patch[4/4]).
> At present, Meson does not support detecting an additional level of subdirectories within drivers/*.
> All the drivers maintain a consistent subdirectory structure.
>>>    ]
>>>    std_deps = ['power']
>>> diff --git a/lib/power/meson.build b/lib/power/meson.build index
>>> f3e3451cdc..9b13d98810 100644
>>> --- a/lib/power/meson.build
>>> +++ b/lib/power/meson.build
>>> @@ -13,7 +13,6 @@ if not is_linux
>>>    endif
>>>    sources = files(
>>>            'power_common.c',
>>> -        'power_intel_uncore.c',
>>>            'rte_power.c',
>>>            'rte_power_uncore.c',
>>>            'rte_power_pmd_mgmt.c',
>>> @@ -24,6 +23,7 @@ headers = files(
>>>            'rte_power_guest_channel.h',
>>>            'rte_power_pmd_mgmt.h',
>>>            'rte_power_uncore.h',
>>> +        'rte_power_uncore_ops.h',
>>>    )
>>>    if cc.has_argument('-Wno-cast-qual')
>>>        cflags += '-Wno-cast-qual'
>>> diff --git a/lib/power/rte_power_uncore.c
>>> b/lib/power/rte_power_uncore.c index 48c75a5da0..9f8771224f 100644
>>> --- a/lib/power/rte_power_uncore.c
>>> +++ b/lib/power/rte_power_uncore.c
>>> @@ -1,6 +1,7 @@
>>>    /* SPDX-License-Identifier: BSD-3-Clause
>>>     * Copyright(c) 2010-2014 Intel Corporation
>>>     * Copyright(c) 2023 AMD Corporation
>>> + * Copyright(c) 2024 Advanced Micro Devices, Inc.
>>>     */
>>>
>>>    #include <errno.h>
>>> @@ -12,98 +13,50 @@
>>>    #include "rte_power_uncore.h"
>>>    #include "power_intel_uncore.h"
>>>
>>> -enum rte_uncore_power_mgmt_env default_uncore_env =
>>> RTE_UNCORE_PM_ENV_NOT_SET;
>>> +static enum rte_uncore_power_mgmt_env global_uncore_env =
>>> +RTE_UNCORE_PM_ENV_NOT_SET; static struct rte_power_uncore_ops
>>> +*global_uncore_ops;
>>>
>>>    static rte_spinlock_t global_env_cfg_lock =
>>> RTE_SPINLOCK_INITIALIZER;
>>> +static RTE_TAILQ_HEAD(, rte_power_uncore_ops) uncore_ops_list =
>>> +                     TAILQ_HEAD_INITIALIZER(uncore_ops_list);
>>>
>>> -static uint32_t
>>> -power_get_dummy_uncore_freq(unsigned int pkg __rte_unused,
>>> -            unsigned int die __rte_unused)
>>> -{
>>> -     return 0;
>>> -}
>>> -
>>> -static int
>>> -power_set_dummy_uncore_freq(unsigned int pkg __rte_unused,
>>> -            unsigned int die __rte_unused, uint32_t index __rte_unused)
>>> -{
>>> -     return 0;
>>> -}
>>> +const char *uncore_env_str[] = {
>>> +     "not set",
>>> +     "auto-detect",
>>> +     "intel-uncore",
>>> +     "amd-hsmp"
>>> +};
>> Why open the "auto-detect" mode to user?
>> Why not set this automatically at framework initialization?
>> After all, the uncore driver is fixed for one platform.
> The auto-detection feature has been implemented to enable seamless migration across platforms
> without requiring any changes to the application
>>> -static int
>>> -power_dummy_uncore_freq_max(unsigned int pkg __rte_unused,
>>> -            unsigned int die __rte_unused)
>>> -{
>>> -     return 0;
>>> -}
>>> -
>> <...>
>>> -static int
>>> -power_dummy_uncore_get_num_freqs(unsigned int pkg __rte_unused,
>>> -            unsigned int die __rte_unused)
>>> +/* register the ops struct in rte_power_uncore_ops, return 0 on
>>> +success. */ int rte_power_register_uncore_ops(struct
>>> +rte_power_uncore_ops *driver_ops)
>>>    {
>>> -     return 0;
>>> -}
>>> +     if (!driver_ops->init || !driver_ops->exit || !driver_ops->get_num_pkgs ||
>>> +             !driver_ops->get_num_dies || !driver_ops->get_num_freqs ||
>>> +             !driver_ops->get_avail_freqs || !driver_ops->get_freq ||
>>> +             !driver_ops->set_freq || !driver_ops->freq_max ||
>>> +             !driver_ops->freq_min) {
>>> +             POWER_LOG(ERR, "Missing callbacks while registering power ops");
>>> +             return -1;
>>> +     }
>>> +     if (driver_ops->cb)
>>> +             driver_ops->cb();
>>>
>>> -static unsigned int
>>> -power_dummy_uncore_get_num_pkgs(void)
>>> -{
>>> -     return 0;
>>> -}
>>> +     TAILQ_INSERT_TAIL(&uncore_ops_list, driver_ops, next);
>>>
>>> -static unsigned int
>>> -power_dummy_uncore_get_num_dies(unsigned int pkg __rte_unused) -{
>>>        return 0;
>>>    }
>>> -
>>> -/* function pointers */
>>> -rte_power_get_uncore_freq_t rte_power_get_uncore_freq =
>>> power_get_dummy_uncore_freq; -rte_power_set_uncore_freq_t
>>> rte_power_set_uncore_freq = power_set_dummy_uncore_freq;
>>> -rte_power_uncore_freq_change_t rte_power_uncore_freq_max =
>>> power_dummy_uncore_freq_max; -rte_power_uncore_freq_change_t
>>> rte_power_uncore_freq_min = power_dummy_uncore_freq_min;
>>> -rte_power_uncore_freqs_t rte_power_uncore_freqs =
>>> power_dummy_uncore_freqs; -rte_power_uncore_get_num_freqs_t
>>> rte_power_uncore_get_num_freqs = power_dummy_uncore_get_num_freqs;
>>> -rte_power_uncore_get_num_pkgs_t rte_power_uncore_get_num_pkgs =
>>> power_dummy_uncore_get_num_pkgs; -rte_power_uncore_get_num_dies_t
>>> rte_power_uncore_get_num_dies = power_dummy_uncore_get_num_dies;
>>> -
>>> -static void
>>> -reset_power_uncore_function_ptrs(void)
>>> -{
>>> -     rte_power_get_uncore_freq = power_get_dummy_uncore_freq;
>>> -     rte_power_set_uncore_freq = power_set_dummy_uncore_freq;
>>> -     rte_power_uncore_freq_max = power_dummy_uncore_freq_max;
>>> -     rte_power_uncore_freq_min = power_dummy_uncore_freq_min;
>>> -     rte_power_uncore_freqs  = power_dummy_uncore_freqs;
>>> -     rte_power_uncore_get_num_freqs = power_dummy_uncore_get_num_freqs;
>>> -     rte_power_uncore_get_num_pkgs = power_dummy_uncore_get_num_pkgs;
>>> -     rte_power_uncore_get_num_dies = power_dummy_uncore_get_num_dies;
>>> -}
>>> -
>>>    int
>>>    rte_power_set_uncore_env(enum rte_uncore_power_mgmt_env env)
>>>    {
>>> -     int ret;
>>> +     int ret = -1;
>>> +     struct rte_power_uncore_ops *ops;
>>>
>>>        rte_spinlock_lock(&global_env_cfg_lock);
>>>
>>> -     if (default_uncore_env != RTE_UNCORE_PM_ENV_NOT_SET) {
>>> +     if (global_uncore_env != RTE_UNCORE_PM_ENV_NOT_SET) {
>>>                POWER_LOG(ERR, "Uncore Power Management Env already set.");
>>> -             rte_spinlock_unlock(&global_env_cfg_lock);
>>> -             return -1;
>>> +             goto out;
>>>        }
>>>
>> <...>
>>> +     if (env <= RTE_DIM(uncore_env_str)) {
>>> +             RTE_TAILQ_FOREACH(ops, &uncore_ops_list, next)
>>> +                     if (strncmp(ops->name, uncore_env_str[env],
>>> +                             RTE_POWER_UNCORE_DRIVER_NAMESZ) == 0) {
>>> +                             global_uncore_env = env;
>>> +                             global_uncore_ops = ops;
>>> +                             ret = 0;
>>> +                             goto out;
>>> +                     }
>>> +             POWER_LOG(ERR, "Power Management (%s) not supported",
>>> +                             uncore_env_str[env]);
>>> +     } else
>>> +             POWER_LOG(ERR, "Invalid Power Management Environment");
>>>
>>> -     default_uncore_env = env;
>>>    out:
>>>        rte_spinlock_unlock(&global_env_cfg_lock);
>>>        return ret;
>>> @@ -139,15 +89,22 @@ void
>>>    rte_power_unset_uncore_env(void)
>>>    {
>>>        rte_spinlock_lock(&global_env_cfg_lock);
>>> -     default_uncore_env = RTE_UNCORE_PM_ENV_NOT_SET;
>>> -     reset_power_uncore_function_ptrs();
>>> +     global_uncore_env = RTE_UNCORE_PM_ENV_NOT_SET;
>>>        rte_spinlock_unlock(&global_env_cfg_lock);
>>>    }
>>>
>> How about abstract an ABI interface to intialize or set the uncore driver on platform
>> by automatical.
>>
>> And later do power_intel_uncore_init_on_die() for each die on different package.
>>>    enum rte_uncore_power_mgmt_env
>>>    rte_power_get_uncore_env(void)
>>>    {
>>> -     return default_uncore_env;
>>> +     return global_uncore_env;
>>> +}
>>> +
>>> +struct rte_power_uncore_ops *
>>> +rte_power_get_uncore_ops(void)
>>> +{
>>> +     RTE_ASSERT(global_uncore_ops != NULL);
>>> +
>>> +     return global_uncore_ops;
>>>    }
>>>
>>>    int
>>> @@ -155,27 +112,29 @@ rte_power_uncore_init(unsigned int pkg, unsigned
>>> int die)
>> This pkg means the socket id on the platform, right?
>> If so, I am not sure that the
>> uncore_info[RTE_MAX_NUMA_NODES][MAX_NUMA_DIE] used in uncore lib is
>> universal for all uncore driver.
>> For example, uncore driver just support do uncore dvfs based on the socket unit.
>> What shoud we do for this? we may need to think twice.
> Yes, pkg represents a socket id. In platforms with a single uncore controller per socket,
> the die ID should be set to '0' for the corresponding socket ID (pkg).
> .
So just use the die ID 0 on one socket ID(namely, uncore_info[0][0], 
uncore_info[1][0]) to initialize the uncore power info on sockets, right?
 From the implement in l3fwd-power, it set all die ID and all sockets.
For the platform with a single uncore controller per socket, their 
uncore driver in DPDK have to ignore other die IDs except die-0 on one 
socket. right?
>>>    {
>>>        int ret = -1;
>>>
>> <...>

  reply	other threads:[~2024-10-22  2:06 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 15:33 [RFC PATCH 0/2] power: refactor power management library Sivaprasad Tummala
2024-02-20 15:33 ` Sivaprasad Tummala
2024-02-20 15:33 ` [RFC PATCH 1/2] power: refactor core " Sivaprasad Tummala
2024-02-27 16:18   ` Ferruh Yigit
2024-02-29  7:10     ` Tummala, Sivaprasad
2024-02-28 12:51   ` Ferruh Yigit
2024-03-01  2:56   ` lihuisong (C)
2024-03-01 10:39     ` Hunt, David
2024-03-05  4:35     ` Tummala, Sivaprasad
2024-02-20 15:33 ` [RFC PATCH 2/2] power: refactor uncore " Sivaprasad Tummala
2024-03-01  3:33   ` lihuisong (C)
2024-03-01  6:06     ` Tummala, Sivaprasad
2024-07-20 16:50 ` [PATCH v1 0/4] power: refactor " Sivaprasad Tummala
2024-07-20 16:50   ` [PATCH v1 1/4] power: refactor core " Sivaprasad Tummala
2024-07-23 10:03     ` Hunt, David
2024-07-27 18:44       ` Tummala, Sivaprasad
2024-07-20 16:50   ` [PATCH v1 2/4] power: refactor uncore " Sivaprasad Tummala
2024-07-23 10:26     ` Hunt, David
2024-07-20 16:50   ` [PATCH v1 3/4] test/power: removed function pointer validations Sivaprasad Tummala
2024-07-22 10:49     ` Hunt, David
2024-07-27 18:45       ` Tummala, Sivaprasad
2024-07-20 16:50   ` [PATCH v1 4/4] power/amd_uncore: uncore power management support for AMD EPYC processors Sivaprasad Tummala
2024-07-23 10:33     ` Hunt, David
2024-07-27 18:46       ` Tummala, Sivaprasad
2024-07-20 16:50   ` [PATCH v1 0/4] power: refactor power management library Sivaprasad Tummala
2024-08-26 13:06   ` [PATCH v2 " Sivaprasad Tummala
2024-08-26 13:06     ` [PATCH v2 1/4] power: refactor core " Sivaprasad Tummala
2024-08-26 15:26       ` Stephen Hemminger
2024-10-07 19:25         ` Tummala, Sivaprasad
2024-08-27  8:21       ` lihuisong (C)
2024-09-12 11:17         ` Tummala, Sivaprasad
2024-09-13  7:34           ` lihuisong (C)
2024-09-18  8:37             ` Tummala, Sivaprasad
2024-09-19  3:37               ` lihuisong (C)
2024-08-26 13:06     ` [PATCH v2 2/4] power: refactor uncore " Sivaprasad Tummala
2024-08-27 13:02       ` lihuisong (C)
2024-10-08  6:19         ` Tummala, Sivaprasad
2024-10-22  2:05           ` lihuisong (C) [this message]
2024-08-26 13:06     ` [PATCH v2 3/4] test/power: removed function pointer validations Sivaprasad Tummala
2024-08-26 13:06     ` [PATCH v2 4/4] power/amd_uncore: uncore power management support for AMD EPYC processors Sivaprasad Tummala
2024-08-26 13:06     ` [PATCH v2 0/4] power: refactor power management library Sivaprasad Tummala
2024-10-07 18:01     ` Stephen Hemminger
2024-10-08 17:27     ` [PATCH v3 0/5] " Sivaprasad Tummala
2024-10-08 17:27       ` [PATCH v3 1/5] power: refactor core " Sivaprasad Tummala
2024-10-08 17:27       ` [PATCH v3 2/5] power: refactor uncore " Sivaprasad Tummala
2024-10-08 17:27       ` [PATCH v3 3/5] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-08 17:27       ` [PATCH v3 4/5] power/amd_uncore: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-08 17:27       ` [PATCH v3 5/5] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-08 17:27       ` [PATCH v3 0/5] power: refactor power management library Sivaprasad Tummala
2024-10-08 17:43       ` Sivaprasad Tummala
2024-10-08 17:43         ` [PATCH v3 1/5] power: refactor core " Sivaprasad Tummala
2024-10-08 17:43         ` [PATCH v3 2/5] power: refactor uncore " Sivaprasad Tummala
2024-10-08 17:43         ` [PATCH v3 3/5] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-08 17:43         ` [PATCH v3 4/5] power/amd_uncore: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-08 17:43         ` [PATCH v3 5/5] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-08 17:43         ` [PATCH v3 0/5] power: refactor power management library Sivaprasad Tummala
2024-10-12 17:44         ` Stephen Hemminger
2024-10-15  2:49       ` [PATCH v4 " Sivaprasad Tummala
2024-10-15  2:49         ` [PATCH v4 1/5] power: refactor core " Sivaprasad Tummala
2024-10-15  2:49         ` [PATCH v4 2/5] power: refactor uncore " Sivaprasad Tummala
2024-10-15  2:49         ` [PATCH v4 3/5] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-15  2:49         ` [PATCH v4 4/5] power/amd_uncore: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-15  2:49         ` [PATCH v4 5/5] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-15  2:49         ` [PATCH v4 0/5] power: refactor power management library Sivaprasad Tummala
2024-10-15  3:15         ` Stephen Hemminger
2024-10-17 10:26         ` [PATCH v5 " Sivaprasad Tummala
2024-10-17 10:26           ` [PATCH v5 1/5] power: refactor core " Sivaprasad Tummala
2024-10-17 10:26           ` [PATCH v5 2/5] power: refactor uncore " Sivaprasad Tummala
2024-10-17 10:26           ` [PATCH v5 3/5] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-17 10:26           ` [PATCH v5 4/5] drivers/power: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-17 10:26           ` [PATCH v5 5/5] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-17 10:26           ` [PATCH v5 0/5] power: refactor power management library Sivaprasad Tummala
2024-10-17 16:17           ` Stephen Hemminger
2024-10-20  9:22           ` [PATCH v6 " Sivaprasad Tummala
2024-10-20  9:22             ` [PATCH v6 1/5] power: refactor core " Sivaprasad Tummala
2024-10-20  9:22             ` [PATCH v6 2/5] power: refactor uncore " Sivaprasad Tummala
2024-10-20 23:25               ` Stephen Hemminger
2024-10-20 23:28               ` Stephen Hemminger
2024-10-20  9:22             ` [PATCH v6 3/5] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-20  9:22             ` [PATCH v6 4/5] drivers/power: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-20  9:22             ` [PATCH v6 5/5] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-20  9:22             ` [PATCH v6 0/5] power: refactor power management library Sivaprasad Tummala
2024-10-21  4:07             ` [PATCH v7 " Sivaprasad Tummala
2024-10-21  4:07               ` [PATCH v7 1/5] power: refactor core " Sivaprasad Tummala
2024-10-22  1:20                 ` Stephen Hemminger
2024-10-22  6:45                   ` Tummala, Sivaprasad
2024-10-22  3:03                 ` lihuisong (C)
2024-10-22  7:13                   ` Tummala, Sivaprasad
2024-10-22  8:36                     ` lihuisong (C)
2024-10-21  4:07               ` [PATCH v7 2/5] power: refactor uncore " Sivaprasad Tummala
2024-10-22  1:18                 ` Stephen Hemminger
2024-10-22  6:45                   ` Tummala, Sivaprasad
2024-10-22  3:17                 ` lihuisong (C)
2024-10-22  6:46                   ` Tummala, Sivaprasad
2024-10-21  4:07               ` [PATCH v7 3/5] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-21  4:07               ` [PATCH v7 4/5] drivers/power: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-21  4:07               ` [PATCH v7 5/5] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-21  4:07               ` [PATCH v7 0/5] power: refactor power management library Sivaprasad Tummala
2024-10-22  1:34               ` Stephen Hemminger
2024-10-22 18:41               ` [PATCH v8 0/6] " Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 1/6] power: refactor core " Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 2/6] power: refactor uncore " Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 3/6] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 4/6] drivers/power: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 5/6] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 6/6] power: rename library sources for cpu frequency management Sivaprasad Tummala
2024-10-22 18:41                 ` [PATCH v8 0/6] power: refactor power management library Sivaprasad Tummala
2024-10-23  1:40                 ` Stephen Hemminger
2024-10-23  5:11                 ` [PATCH v9 " Sivaprasad Tummala
2024-10-23  5:11                   ` [PATCH v9 1/6] power: refactor core " Sivaprasad Tummala
2024-10-26  3:06                     ` lihuisong (C)
2024-10-26  5:22                       ` Tummala, Sivaprasad
2024-10-26  7:03                         ` lihuisong (C)
2024-10-23  5:11                   ` [PATCH v9 2/6] power: refactor uncore " Sivaprasad Tummala
2024-10-26  3:12                     ` lihuisong (C)
2024-10-23  5:11                   ` [PATCH v9 3/6] test/power: removed function pointer validations Sivaprasad Tummala
2024-10-23  5:11                   ` [PATCH v9 4/6] drivers/power: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-10-23  5:11                   ` [PATCH v9 5/6] maintainers: update for drivers/power Sivaprasad Tummala
2024-10-23  5:11                   ` [PATCH v9 6/6] power: rename library sources for cpu frequency management Sivaprasad Tummala
2024-10-26  4:09                     ` lihuisong (C)
2024-10-23  5:11                   ` [PATCH v9 0/6] power: refactor power management library Sivaprasad Tummala
2024-10-28 19:55                   ` [PATCH v10 " Sivaprasad Tummala
2024-10-28 19:55                     ` [PATCH v10 1/6] power: refactor core " Sivaprasad Tummala
2024-11-10 10:40                       ` Thomas Monjalon
2024-10-28 19:55                     ` [PATCH v10 2/6] power: refactor uncore " Sivaprasad Tummala
2024-11-16  0:55                       ` Stephen Hemminger
2024-10-28 19:55                     ` [PATCH v10 3/6] test/power: removed function pointer validations Sivaprasad Tummala
2024-11-10 10:11                       ` Thomas Monjalon
2024-10-28 19:55                     ` [PATCH v10 4/6] drivers/power: uncore support for AMD EPYC processors Sivaprasad Tummala
2024-11-10 10:52                       ` Thomas Monjalon
2024-10-28 19:55                     ` [PATCH v10 5/6] maintainers: update for drivers/power Sivaprasad Tummala
2024-11-10 10:54                       ` Thomas Monjalon
2024-10-28 19:55                     ` [PATCH v10 6/6] power: rename library sources for cpu frequency management Sivaprasad Tummala
2024-11-10 18:35                     ` [PATCH v10 0/6] power: refactor power management library Thomas Monjalon
2024-11-10 19:29                       ` Stephen Hemminger
2024-11-10 23:40                         ` Thomas Monjalon
2024-11-12  8:20                       ` David Marchand
2024-11-12 10:37                         ` David Marchand
2024-11-12 14:50                           ` Tummala, Sivaprasad

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=d339c98e-d1b7-1b66-5376-6f84aa94e705@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=Ferruh.Yigit@amd.com \
    --cc=Sivaprasad.Tummala@amd.com \
    --cc=anatoly.burakov@intel.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=david.hunt@intel.com \
    --cc=dev@dpdk.org \
    --cc=gakhil@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@huawei.com \
    --cc=radu.nicolau@intel.com \
    /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).