Hi Connor,
On 19/4/2021 1:29 PM, Min Hu (Connor) wrote:
The return value of 'rte_eal_cleanup' is always zero, so comparison
with zero is redundant.
This patch fixed it by deleting the redundant comparison.
Fixes: 67684d1e87b6 ("app/procinfo: call EAL cleanup before exit")
Fixes: b68a82425da4 (
On 15/4/2021 6:59 AM, Richael Zhuang wrote:
For some platforms the newly-set frequency may not be effective
immediately. If we didn't get the right value from cpuinfo_cur_freq
immediately, add 10ms delay each time before rechecking until
timeout.
From our test, for some arm platforms, it requ
On 20/4/2021 1:38 PM, David Hunt wrote:
On 15/4/2021 6:59 AM, Richael Zhuang wrote:
For some platforms the newly-set frequency may not be effective
immediately. If we didn't get the right value from cpuinfo_cur_freq
immediately, add 10ms delay each time before rechecking until
ti
his, rounds nicely. I found an unrelated issue
around turbo mode that I need to look at but this patch looks fine.
Reviewed-by: David Hunt
power manager unit tests")
Cc: sta...@dpdk.org
Signed-off-by: David Hunt
---
app/test/test_power_cpufreq.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/app/test/test_power_cpufreq.c b/app/test/test_power_cpufreq.c
index f753d24ac5..52f58ef8b2 100644
---
With the intel_pstate driver and turbo enabled, indexing is slightly
different to normal, so to get the test to work properly, enable
turbo at the start.
Fixes: ed7c51a6a680 ("app/test: vm power management")
Cc: sta...@dpdk.org
Signed-off-by: David Hunt
---
app/test/test_power_cpu
expected (turbo mode), in which
case the check should be successful.
Fixes: aeaeaf5f2d62 ("test/power: add cases for turbo feature")
Cc: sta...@dpdk.org
Signed-off-by: David Hunt
---
app/test/test_power_cpufreq.c | 27 +++
1 file changed, 15 insertions(+), 12
when turbo is enabled or disabled, the frequency is set to a low non-turbo
frequency, so we need to set to the frequency expected by the test before
checking.
Fixes: aeaeaf5f2d62 ("test/power: add cases for turbo feature")
Cc: sta...@dpdk.org
Signed-off-by: David Hunt
---
RTE_LOG(INFO, CHANNEL_MANAGER, "Channel(%u) is out of range
"
"0...%d\n",
channel_list[i],
Thanks, Reshma.
The rte_lcore_index() call was incorrectly comparing virtual core_id
against the list of physical core_ids.
Reviewed-by: David Hunt
h resolves the issue.
Reviewed-by: David Hunt
e issue as the ixgbe, get_monitor_addr op missing for the vf portion
of the driver. Thanks.
Reviewed-by: David Hunt
rte_eal_mp_wait_lcore();
quit = 0;
worker_idx = 0;
Tested-by: Lukasz Wojciechowski
Reviewed-by: Lukasz Wojciechowski
Thanks, Stanislaw, Lukasz.
Acked-by: David Hunt
On 28/4/2021 1:53 PM, Stanisław Kardach wrote:
On Wed, Apr 28, 2021 at 2:51 PM David Hunt <mailto:david.h...@intel.com>> wrote:
Thanks, Stanislaw, Lukasz.
Acked-by: David Hunt mailto:david.h...@intel.com>>
Just to be sure, may I send the non-RFC patch without the qu
From: Anatoly Burakov
Currently, ACPI code uses rte_power_info as the struct name, which
gives the appearance that this is an externally visible API. Fix to
use internal namespace.
Signed-off-by: Anatoly Burakov
Acked-by: David Hunt
---
lib/power/power_acpi_cpufreq.c | 34
-off-by: Anatoly Burakov
Signed-off-by: David Hunt
---
changes in v2
* fixed bugs raised by Richael Zhuang in review - open file rw+, etc.
* removed FOPS* and FOPEN* macros, which contained control statements.
* fixed some checkpatch warnings.
---
lib/power/meson.build| 7 +
lib
From: Anatoly Burakov
Currently, ACPI code uses rte_power_info as the struct name, which
gives the appearance that this is an externally visible API. Fix to
use internal namespace.
Signed-off-by: Anatoly Burakov
Acked-by: David Hunt
---
lib/power/power_acpi_cpufreq.c | 34
-off-by: Anatoly Burakov
Signed-off-by: David Hunt
---
changes in v2
* fixed bugs raised by Richael Zhuang in review - open file rw+, etc.
* removed FOPS* and FOPEN* macros, which contained control statements.
* fixed some checkpatch warnings.
---
lib/power/meson.build| 7 +
lib
On 22/6/2021 1:43 PM, David Hunt wrote:
From: Anatoly Burakov
Currently, ACPI code uses rte_power_info as the struct name, which
gives the appearance that this is an externally visible API. Fix to
use internal namespace.
Signed-off-by: Anatoly Burakov
Acked-by: David Hunt
---
lib/power
On 22/6/2021 1:43 PM, David Hunt wrote:
From: Anatoly Burakov
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
Adding people to the CC list that were on v4 of this patch set, and
Richael who raised some issues in v4.
On 22/6/2021 1:58 PM, David Hunt wrote:
From: Anatoly Burakov
Currently, ACPI and PSTATE modes have lots of code duplication,
confusing logic, and a bunch of other issues that can, and
--pmg-mgmt=baseline.
Signed-off-by: David Hunt
---
changes in v2
* added a bool for baseline mode rather than abusing enums
---
examples/l3fwd-power/main.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/ma
fflush(f);
+ if (ret != 0)
+ return -1;
+
+ return 0;
+}
Best regards,
Richael
-Original Message-
From: David Hunt
Sent: Tuesday, June 22, 2021 9:28 PM
To: dev@dpdk.org
Cc: anatoly.bura...@intel.com; step...@networkplumber.org; Richael
Zhuang ; Reshma Pattan
; nd
Sub
From: Anatoly Burakov
Currently, ACPI code uses rte_power_info as the struct name, which
gives the appearance that this is an externally visible API. Fix to
use internal namespace.
Signed-off-by: Anatoly Burakov
Acked-by: David Hunt
---
lib/power/power_acpi_cpufreq.c | 34
-off-by: Anatoly Burakov
Signed-off-by: David Hunt
---
changes in v5
* fixed bugs raised by Richael Zhuang in review - open file rw+, etc.
* removed FOPS* and FOPEN* macros, which contained control statements.
* fixed some checkpatch warnings.
changes in v6
* fixed check of fputs return, negative
On 23/6/2021 11:14 AM, Burakov, Anatoly wrote:
On 22-Jun-21 3:07 PM, David Hunt wrote:
The PMD Power Management scheme currently has 3 modes,
scale, monitor and pause. However, it would be nice to
have a baseline mode for easy comparison of power savings
with and without these modes.
This
macros need to be removed to bring in line with the latest (v6) patch
for the cleanup work, a few people have been wanting to remove those
macros for a while now :)
Once that's done, this patch looks good to me, although I can't give it
a run as I don't have access to a sui
uang
---
app/test/test_power_cpufreq.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
--snip--
Makes sense.
Reviewed-by: David Hunt
Hi Anatoly,
On 29/6/2021 4:48 PM, Anatoly Burakov wrote:
Currently, there is a hard limitation on the PMD power management
support that only allows it to support a single queue per lcore. This is
not ideal as most DPDK use cases will poll multiple queues per core.
The PMD power management mecha
On 30/6/2021 10:52 AM, David Hunt wrote:
Hi Anatoly,
On 29/6/2021 4:48 PM, Anatoly Burakov wrote:
Currently, there is a hard limitation on the PMD power management
support that only allows it to support a single queue per lcore. This is
not ideal as most DPDK use cases will poll multiple
On 5/7/2021 4:22 PM, Anatoly Burakov wrote:
Currently, there is a hard limitation on the PMD power management
support that only allows it to support a single queue per lcore. This is
not ideal as most DPDK use cases will poll multiple queues per core.
The PMD power management mechanism relies
wer savings are back
as expected when low traffic in both monitor and pause modes. All
previous issues seem now to be resolved.
Patch set LGTM.
Tested-by: David Hunt
v2:
- Use callback mechanism for more flexibility
- Address feedback from Konstantin
Tested-by: David Hunt
en available to use. Once this was done, I was then
able to successfully see power saving when a core was configuired with
multiple queues.
Tested-by: David Hunt
d, and document this limitation. This greatly simplifies the
`rte_power_monitor`-related code.
Signed-off-by: Anatoly Burakov
---
Notes:
v2:
- Add check for stopped queue
- Clarified doc message
- Added release notes
Tested-by: David Hunt
is not supported by the hardware.
Signed-off-by: Anatoly Burakov
---
Notes:
v6:
- Fix the missed feedback from v5
v4:
- Fix possible out of bounds access
- Added missing index increment
--snip--
Tested-by: David Hunt
wer management mode, only one queue per
lcore is allowed\n");
- }
-
/* init RX queues */
for(queue = 0; queue < qconf->n_rx_queue; ++queue) {
struct rte_eth_rxconf rxq_conf;
Tested-by: David Hunt
Hi Richael,
On 25/6/2021 3:02 AM, Richael Zhuang wrote:
Currently in DPDK only acpi_cpufreq and pstate_cpufreq drivers are
supported, which are both not available on arm64 platforms. Add
support for cppc_cpufreq driver which works on most arm64 platforms.
Signed-off-by: Richael Zhuang
---
H
on't have access
to a suitable machine. LGTM.
Acked-by: David Hunt
test_power_cpufreq.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
Acked-by: David Hunt
val is fine.
Acked-by: David Hunt
/rte_distributor_single.c| 2 --
3 files changed, 6 deletions(-)
Acked-by: David Hunt
/rte_power.h | 2 --
lib/power/rte_power_empty_poll.c | 2 --
14 files changed, 1 insertion(+), 40 deletions(-)
Acked-by: David Hunt
(ep_params != NULL)
- rte_free(ep_params);
+ rte_free(ep_params);
}
int
Acked-by: David Hunt
-by: David Hunt
anged, 181 insertions(+), 5 deletions(-)
Tested-by: David Hunt
lib/power/rte_power_pmd_mgmt.c | 25 +++--
lib/power/rte_power_pmd_mgmt.h | 31 +++
lib/power/version.map | 2 ++
3 files changed, 56 insertions(+), 2 deletions(-)
Tested-by: David Hunt
/rte_power_pmd_mgmt.h | 27 +++
lib/power/version.map | 4
3 files changed, 49 insertions(+), 3 deletions(-)
Tested-by: David Hunt
ret = rte_eth_dev_configure(portid, nb_rx_queue,
(uint16_t)n_tx_queue, &local_port_conf);
if (ret < 0)
--
2.25.1
Reviewed-by: Chenbo Xia
LGTM.
Acked-by: David Hunt
On 21/10/2021 5:48 PM, Ferruh Yigit wrote:
On 10/18/2021 3:16 PM, Miao Li wrote:
Since some vdevs like virtio and vhost do not support rxq_info_get and
queue state inquiry, the error return value -ENOTSUP need to be ignored
when queue_stopped cannot get rx queue information and rx queue state.
tats_get_names,
.rx_queue_intr_enable = eth_rxq_intr_enable,
.rx_queue_intr_disable = eth_rxq_intr_disable,
+ .get_monitor_addr = vhost_get_monitor_addr,
};
static int
--
2.25.1
Reviewed-by: Chenbo Xia
Acked-by: David Hunt
RTE_LOG_REGISTER_SUFFIX(vhost_config_log_level, config, INFO);
RTE_LOG_REGISTER_SUFFIX(vhost_data_log_level, data, WARNING);
--
2.25.1
Reviewed-by: Chenbo Xia
Acked-by: David Hunt
pmc->opaque[CLB_MSK_IDX] = vq->vq_nentries - 1;
+ pmc->opaque[CLB_MATCH_IDX] = 0;
+ pmc->size = sizeof(vq->vq_split.ring.used->idx);
+ }
+ pmc->fn = virtio_monitor_callback;
+
+ return 0;
+}
+
static int
virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
{
LGTM.
Acked-by: David Hunt
be fixed in merge time.
Acked-by: Jerin Jacob
Acked-by David Hunt
---
lib/distributor/rte_distributor_single.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lib/distributor/rte_distributor_single.c
b/lib/distributor/rte_distributor_single.c
index
Hi David,
On 2/11/2021 5:45 PM, David Marchand wrote:
On Thu, Sep 23, 2021 at 1:03 PM David Hunt wrote:
If the user requests to use an lcore above 128 using -c,
the eal will exit with "EAL: invalid coremask syntax" and
very little else useful information.
This patch adds
On 3/11/2021 10:27 AM, David Hunt wrote:
Hi David,
On 2/11/2021 5:45 PM, David Marchand wrote:
On Thu, Sep 23, 2021 at 1:03 PM David Hunt wrote:
If the user requests to use an lcore above 128 using -c,
the eal will exit with "EAL: invalid coremask syntax" and
very little e
AX_LCORE (128)
EAL: to use high physical core ids , please use --lcores to map
them to lcore ids below RTE_MAX_LCORE,
EAL: e.g. --lcores 0@12,1@13,2@14,3@15,4@16,5@132,6@133
Signed-off-by: David Hunt
Acked-by: Bruce Richardson
---
changes in v6
* none
changes in v5
* removed un-neede
RE (128)
EAL: lcore 129 >= RTE_MAX_LCORE (128)
EAL: to use high physical core ids , please use --lcores to
map them to lcore ids below RTE_MAX_LCORE,
EAL: e.g. --lcores 0@128,1@129
Signed-off-by: David Hunt
Acked-by: Bruce Richardson
---
changes in v6
* Fixed typo (gto -> got).
* Removed dead cod
nging max_lcores default from 128 to 512.
Signed-off-by: David Hunt
---
lib/power/power_cppc_cpufreq.c | 111 +++--
1 file changed, 93 insertions(+), 18 deletions(-)
diff --git a/lib/power/power_cppc_cpufreq.c b/lib/power/power_cppc_cpufreq.c
index 6afd310e4e..952daf312e 1
27;re changing max_lcores default from 128 to 512.
Signed-off-by: David Hunt
---
lib/power/power_kvm_vm.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/lib/power/power_kvm_vm.c b/lib/power/power_kvm_vm.c
index ab7d4b8cee..c60e7acf16 100644
---
empty poll algorithm uses NUM_NODES as 256, but should really use
RTE_MAX_LCORE, which is configurable.
Signed-off-by: David Hunt
---
lib/power/rte_power_empty_poll.c | 12 ++--
lib/power/rte_power_empty_poll.h | 4 +---
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a
Add non-interactive mode to dpdk-telemetry.py so that a query string
can be supplied on the command line, and script dumps out data and
exits. Handing for calling from scripts.
Signed-off-by: David Hunt
---
usertools/dpdk-telemetry.py | 22 ++
1 file changed, 14 insertions
+0100, David Hunt wrote:
Modern processors are coming with an ever increasing number of cores,
and 128 does not seem like a sensible max limit any more, especially
when you consider multi-socket systems with Hyper-Threading enabled.
This patch increases max_lcores default from 128 to 512.
Signed
On 14/9/2021 11:00 AM, David Marchand wrote:
On Tue, Sep 14, 2021 at 11:34 AM David Hunt wrote:
On 10/9/2021 9:24 AM, Thomas Monjalon wrote:
10/09/2021 10:06, David Marchand:
On Fri, Sep 10, 2021 at 9:54 AM Bruce Richardson
wrote:
On Fri, Sep 10, 2021 at 08:51:04AM +0200, David Marchand
at 11:43:25AM +0100, Bruce Richardson wrote:
On Thu, Sep 09, 2021 at 04:56:25PM +0100, David Hunt wrote:
Add non-interactive mode to dpdk-telemetry.py so that a query string
can be supplied on the command line, and script dumps out data and
exits. Handing for calling from scripts.
Signed-off-by
-14,130,132" is used, we
see the following additional output on the command line:
EAL: Error = One of the 5 cores provided exceeds RTE_MAX_LCORE (128)
EAL: Please use --lcores instead, e.g. --lcores 0@12,1@13,2@14,3@130,4@132
Signed-off-by: David Hunt
---
changes in v2
* Rather than increa
On 14/9/2021 12:29 PM, David Marchand wrote:
On Tue, Sep 14, 2021 at 1:07 PM David Hunt wrote:
“ERROR: logical core 212 is above the maximum lcore number permitted.
Please use the --lcores option to map lcores onto physical cores, e.g.
--lcores="(0-3)@(212-215).”
If you could dir
Hi David,
On 16/9/2021 1:34 PM, David Marchand wrote:
On Wed, Sep 15, 2021 at 2:11 PM David Hunt wrote:
If the user requests to use an lcore above 128 using -l or -c,
the eal will exit with "EAL: invalid core list syntax" and
very little other useful information.
This patch adds
uot; is used, we
see the following additional output on the command line:
EAL: Error = One of the 7 cores provided exceeds RTE_MAX_LCORE (128)
EAL: Please use --lcores instead, e.g.
--lcores 0@12,1@13,2@14,3@15,4@16,5@130,6@132
Signed-off-by: David Hunt
---
changes in v2
* Rather than in
le, if
"-c 0xf" is used, we see the
following additional output on the command line:
EAL: Error = One of the 4 cores provided exceeds RTE_MAX_LCORE (128)
EAL: Please use --lcores instead, e.g. --lcores 0@128,1@129,2@130,3@131
Signed-off-by: David Hunt
---
changes in v3
* added t
On 21/9/2021 12:57 PM, Bruce Richardson wrote:
On Tue, Sep 21, 2021 at 12:50:14PM +0100, David Hunt wrote:
If the user requests to use an lcore above 128 using -l,
the eal will exit with "EAL: invalid core list syntax" and
very little else useful information.
THis patch adds
On 21/9/2021 1:04 PM, David Hunt wrote:
On 21/9/2021 12:57 PM, Bruce Richardson wrote:
On Tue, Sep 21, 2021 at 12:50:14PM +0100, David Hunt wrote:
If the user requests to use an lcore above 128 using -l,
the eal will exit with "EAL: invalid core list syntax" and
very little e
On 21/9/2021 2:51 PM, David Marchand wrote:
On Tue, Sep 21, 2021 at 1:50 PM David Hunt wrote:
static int
eal_parse_coremask(const char *coremask, int *cores)
{
@@ -839,54 +880,89 @@ eal_parse_service_corelist(const char *corelist)
static int
eal_parse_corelist(const char *corelist
RE (128)
EAL: lcore 129 >= RTE_MAX_LCORE (128)
EAL: to use high physical core ids , please use --lcores to
map them to lcore ids below RTE_MAX_LCORE,
EAL: e.g. --lcores 0@128,1@129
Signed-off-by: David Hunt
Acked-by: Bruce Richardson
---
changes in v3
* added this patch to the set. Addresses the chan
AX_LCORE (128)
EAL: to use high physical core ids , please use --lcores to map
them to lcore ids below RTE_MAX_LCORE,
EAL: e.g. --lcores 0@12,1@13,2@14,3@15,4@16,5@132,6@133
Signed-off-by: David Hunt
Acked-by: Bruce Richardson
---
changes in v2
* Rather than increasing the default max lcor
On 23/9/2021 9:11 AM, David Marchand wrote:
On Wed, Sep 22, 2021 at 2:29 PM David Hunt wrote:
If the user requests to use an lcore above 128 using -l,
the eal will exit with "EAL: invalid core list syntax" and
very little else useful information.
This patch adds some extra i
On 23/9/2021 9:12 AM, David Marchand wrote:
On Wed, Sep 22, 2021 at 2:29 PM David Hunt wrote:
int i, j, idx;
int val;
char c;
+ int lcores[RTE_MAX_LCORE];
+ char *coremask_copy = NULL;
Contrary to patch 1, coremask_copy is used.
But, coremask is const
AX_LCORE (128)
EAL: to use high physical core ids , please use --lcores to map
them to lcore ids below RTE_MAX_LCORE,
EAL: e.g. --lcores 0@12,1@13,2@14,3@15,4@16,5@132,6@133
Signed-off-by: David Hunt
Acked-by: Bruce Richardson
---
changes in v2
* Rather than increasing the default max lcor
RE (128)
EAL: lcore 129 >= RTE_MAX_LCORE (128)
EAL: to use high physical core ids , please use --lcores to
map them to lcore ids below RTE_MAX_LCORE,
EAL: e.g. --lcores 0@128,1@129
Signed-off-by: David Hunt
Acked-by: Bruce Richardson
---
changes in v3
* added this patch to the set. Addresses the chan
On 8/7/2021 1:49 PM, David Marchand wrote:
On Wed, Jun 23, 2021 at 2:04 PM David Hunt wrote:
From: Anatoly Burakov
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
-off-by: Anatoly Burakov
Signed-off-by: David Hunt
---
changes in v5
* fixed bugs raised by Richael Zhuang in review - open file rw+, etc.
* removed FOPS* and FOPEN* macros, which contained control statements.
* fixed some checkpatch warnings.
changes in v6
* fixed check of fputs return, negative
From: Anatoly Burakov
Currently, ACPI code uses rte_power_info as the struct name, which
gives the appearance that this is an externally visible API. Fix to
use internal namespace.
Signed-off-by: Anatoly Burakov
Acked-by: David Hunt
---
lib/power/power_acpi_cpufreq.c | 34
On 9/7/2021 4:34 AM, Richael Zhuang wrote:
Currently in DPDK only acpi_cpufreq and pstate_cpufreq drivers are
supported, which are both not available on arm64 platforms. Add
support for cppc_cpufreq driver which works on most arm64 platforms.
Signed-off-by: Richael Zhuang
---
--snip--
Hi
On 9/7/2021 4:09 PM, David Marchand wrote:
On Fri, Jul 9, 2021 at 5:02 PM Anatoly Burakov
wrote:
Currently, the error paths can lead to attempts at dereferencing NULL
pointers. Add the check to avoid attempts at dereferencing NULL
pointers.
Coverity issue: 371895
This patch also fixes
C
On 14/7/2021 9:44 AM, Richael Zhuang wrote:
For acpi_cpufreq and cppc_cpufreq, both cpuinfo_cur_freq and
scaling_cur_freq exist. For pstate, only scaling_cur_freq exists.
And value in scaling_cur_freq and cpuinfo_cur_freq may not be the
same. For acpi_cpufreq and cppc_cpufreq, we should check
c
On 14/7/2021 10:23 AM, Richael Zhuang wrote:
-Original Message-
From: David Hunt
Sent: Wednesday, July 14, 2021 5:15 PM
To: Richael Zhuang ; dev@dpdk.org
Cc: zhiminx.hu...@intel.com; sta...@dpdk.org
Subject: Re: [PATCH v1 1/1] test/power: check cpuinfo cur freq before scaling
cur
then freq_conv=80
Looks good now. I ran the power_cpufreq_autotest test on both the
acpi-cpufreq and pstate drivers, and both passed.
Acked-by: David Hunt
("distributor: add new burst-capable library")
Cc: sta...@dpdk.org
Signed-off-by: David Hunt
---
lib/distributor/rte_distributor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/distributor/rte_distributor.c
b/lib/distributor/rte_distributor.c
index 07e385a259..c210cf8
a core, now with this patch, succeeds.
Tested-by: David Hunt
| 5 +
lib/power/power_pstate_cpufreq.c | 5 +
2 files changed, 10 insertions(+)
---snip---
LGTM to fix the coverity issue.
Acked-by: David Hunt
Hi Li,
On 16/11/2021 1:00 PM, Miao Li wrote:
This patch adds a log in main telemetry loop to show the thread is
waked up and begins to send and receive packets.
Signed-off-by: Miao Li
---
examples/l3fwd-power/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/examples/l3fwd-power
nb_rx == 0))
continue;
Acked-by: David Hunt
suggested.
@David Hunt, do you have idea about the memory cost of increasing from 128 to
512? This seems to be the primary objection.
-Morten
Hi Morten,
I seem to recall that a simple increase from 128 to 512 cores would
result in an increased static memory footprint of 2.5MBs per
application, but
: 931e3a994597 ("examples/l3fwd-power: add wakeup log")
Signed-off-by: David Hunt
---
examples/l3fwd-power/main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 5c5825166d..b8b3be2b8a 100644
--- a/examples/l3fwd-power/ma
When using PMD Power Management, scale mode reacts slower than
monitor mode and pause mode. Add note in user guide to this
effect.
Signed-off-by: David Hunt
---
doc/guides/prog_guide/power_man.rst | 4 +++-
doc/guides/sample_app_ug/l3_forward_power_man.rst | 5 +++--
2 files
On 20/1/2021 2:28 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the new header
file into the installation directory.
Fixes: 210c383e247b ("power: packet format for vm power man
On 20/1/2021 2:27 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
rename the public structs to have an rte_power_ prefix.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communi
On 20/1/2021 2:26 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Move the 2 public functions into rte_power_guest_channel.h
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: v
On 20/1/2021 3:09 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
In preparation for making the header file public, we first rename
channel_commands.h as rte_power_guest_channel.h.
Fixes: 210c383e247b ("power: packet format for vm power manag
On 20/1/2021 3:18 PM, Burakov, Anatoly wrote:
On 20-Jan-21 3:08 PM, Bruce Richardson wrote:
On Wed, Jan 20, 2021 at 02:28:59PM +, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the
The guest channel message definitions and functions in guest_channel.h
are needed by applications and need to be made public.
This worked pre-20.11, but now with all the meson/ninja changes, making
these apps externally no longer works. To fix, we need to move the
header file with the API definiti
1 - 100 of 840 matches
Mail list logo
