power: refactor core power management

This patch introduces a comprehensive refactor to the core power
management library. The primary focus is on improving modularity
and organization by relocating

power: refactor core power management

This patch introduces a comprehensive refactor to the core power
management library. The primary focus is on improving modularity
and organization by relocating specific driver implementations
from the 'lib/power' directory to dedicated directories within
'drivers/power/*'. The adjustment of meson.build files
enables the selective activation of individual drivers.

These changes contribute to a significant enhancement in code
organization, providing a clearer structure for driver implementations.
The refactor aims to improve overall code clarity and boost
maintainability. Additionally, it establishes a foundation for
future development, allowing for more focused work on individual
drivers and seamless integration of forthcoming enhancements.

Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
Acked-by: Huisong Li <lihuisong@huawei.com>

show more ...

power: fix mapped lcore ID

This commit fixes an issue in the power library
related to using lcores mapped to different
physical cores (--lcores option in EAL).

Previously, the power library incorre

power: fix mapped lcore ID

This commit fixes an issue in the power library
related to using lcores mapped to different
physical cores (--lcores option in EAL).

Previously, the power library incorrectly accessed
CPU sysfs attributes for power management, treating
lcore IDs as CPU IDs.
e.g. with --lcores '1@128', lcore_id '1' was interpreted
as CPU_id instead of '128'.

This patch corrects the cpu_id based on lcore and CPU
mappings. It also constraints power management support
for lcores mapped to multiple physical cores/threads.

When multiple lcores are mapped to the same physical core,
invoking frequency scaling APIs on any lcore will apply the
changes effectively.

Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")
Cc: stable@dpdk.org

Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Huisong Li <lihuisong@huawei.com>

show more ...

lib: replace logging helpers

This is a preparation step before the next change.

Many libraries have their own logging helpers that do not add a newline
in their format string.
Some previous changes

lib: replace logging helpers

This is a preparation step before the next change.

Many libraries have their own logging helpers that do not add a newline
in their format string.
Some previous changes fixed places where some of those helpers are
called without a trailing newline.
Using RTE_LOG_LINE in the existing helpers will ensure we don't
introduce new issues in the future.

The problem is that if we simply convert to the RTE_LOG_LINE helper,
a future fix may introduce a regression since the logging helper
change won't be backported.

To address this concern, rename existing helpers: backporting a call to
them will trigger some conflict or build issue in LTS branches.

Note:
- bpf and vhost that still has some debug multilines messages, a direct
call to RTE_LOG/RTE_LOG_DP is used: this will make it easier to notice
such special cases,
- about previously publicly exposed logging helpers, when such helper is
not publicly used (iow in public inline API), it is removed from the
public API (this is the case for the member library),

Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

show more ...

lib: add more logging helpers

Add helpers for logging messages in libraries instead of calling
RTE_LOG() directly.
Those helpers take care of adding a \n: this will make the transition to
RTE_LOG_LI

lib: add more logging helpers

Add helpers for logging messages in libraries instead of calling
RTE_LOG() directly.
Those helpers take care of adding a \n: this will make the transition to
RTE_LOG_LINE trivial.

Note:
- for acl and sched libraries that still has some debug multilines
messages, a direct call to RTE_LOG is used: this will make it easier to
notice such special cases,

Signed-off-by: David Marchand <david.marchand@redhat.com>

show more ...

power: use a dynamic logtype

Use dynamic log type for power library.

Convert existing examples with either writing to stderr, or their own
dynamic logtype.

Signed-off-by: Stephen Hemminger <stephe

power: use a dynamic logtype

Use dynamic log type for power library.

Convert existing examples with either writing to stderr, or their own
dynamic logtype.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: David Hunt <david.hunt@intel.com>

show more ...

power: refactor ACPI and intel_pstate support

Currently, ACPI and PSTATE modes have lots of code duplication,
confusing logic, and a bunch of other issues that can, and have, led to
various bugs and

power: refactor ACPI and intel_pstate support

Currently, ACPI and PSTATE modes have lots of code duplication,
confusing logic, and a bunch of other issues that can, and have, led to
various bugs and resource leaks.

This commit factors out the common parts of sysfs reading/writing for
ACPI and PSTATE drivers.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Signed-off-by: David Hunt <david.hunt@intel.com>

show more ...

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
m

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...