for a
discussion
of whether support for this change seems feasible for dynamic mode.
Thanks,
Don
On 9/14/2022 5:12 PM, Don Wallwork wrote:
This patch maps hugepage memory such that address translation from
virtual to iova or vice versa can be done by simple addition/
subtraction of a constant
On 9/15/2022 3:40 AM, Morten Brørup wrote:
From: Don Wallwork [mailto:d...@xsightlabs.com]
Sent: Wednesday, 14 September 2022 23.12
This patch maps hugepage memory such that address translation from
virtual to iova or vice versa can be done by simple addition/
subtraction of a constant value
This patch maps hugepage memory such that address translation from
virtual to iova or vice versa can be done by simple addition/
subtraction of a constant value without any page table walks.
A new '--const-translate' EAL option is added to enable this mode.
The following example describes how thi
happen to be allocated statically (legacy mode) or
dynamically.
The unused VA address space from 3G-7G and 9G-12G can be
unmapped in just two unmap calls.
This patch applies to legacy-mem mode only.
Signed-off-by: Don Wallwork
---
doc/guides/linux_gsg/eal_args.include.rst | 5 +
.../
On 7/28/2022 10:46 AM, Don Wallwork wrote:
Let me try to give a trivial example of how it would work
to make sure we're on the same page and then we can get
back to details..
Thanks you, Don.
Now it's perfectly clear what EAL should do and we can discuss API.
I think this RFC is an
On 7/28/2022 7:29 AM, Morten Brørup wrote:
Let me try to give a trivial example of how it would work
to make sure we're on the same page and then we can get
back to details..
Thanks you, Don.
Now it's perfectly clear what EAL should do and we can discuss API.
I think this RFC is an excellent pr
On 7/27/2022 4:36 PM, Dmitry Kozlyuk wrote:
I now understand more about_why_ you want this feature
but became less confident_what_ do you're proposing specifically.
Let me try to give a trivial example of how it would work
to make sure we're on the same page and then we can get
back to detail
On 7/27/2022 3:12 PM, Stephen Hemminger wrote:
On Wed, 27 Jul 2022 13:20:22 -0400
Don Wallwork wrote:
When drivers need to process a large number of memory blocks,
these are typically packets in the form of mbufs,
which already have IOVA attached, so there is no translation.
Does translation
On 7/26/2022 3:59 PM, Dmitry Kozlyuk wrote:
Hi Don,
2022-07-26 14:33 (UTC-0400), Don Wallwork:
This proposal describes a method for translating any huge page
address from virtual to physical or vice versa using simple
addition or subtraction of a single fixed value. This allows
devices to
This proposal describes a method for translating any huge page
address from virtual to physical or vice versa using simple
addition or subtraction of a single fixed value. This allows
devices to efficiently access arbitrary huge page memory, even
stack data when worker stacks are in huge pages.
W
This proposal describes a method for translating any huge page
address from virtual to physical or vice versa using simple
addition or subtraction of a single fixed value. This allows
devices to efficiently access arbitrary huge page memory, even
stack data when worker stacks are in huge pages.
W
feature to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
Acked-by: Morten Brørup
Acked-by: Chengwen Feng
---
app/test/test_eal_flags.c | 36 ++
doc/guides/linux_gsg/eal_args.include.rst
On 6/21/2022 10:42 AM, Thomas Monjalon wrote:
21/06/2022 14:31, Don Wallwork:
On 6/21/2022 6:37 AM, Thomas Monjalon wrote:
20/06/2022 10:35, David Marchand:
On Tue, May 24, 2022 at 9:52 PM Don Wallwork wrote:
Add support for using hugepages for worker lcore stack memory. The
intent is to
On 6/21/2022 6:37 AM, Thomas Monjalon wrote:
20/06/2022 10:35, David Marchand:
On Tue, May 24, 2022 at 9:52 PM Don Wallwork wrote:
Add support for using hugepages for worker lcore stack memory. The
intent is to improve performance by reducing stack memory related TLB
misses and also by using
feature to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
Acked-by: Morten Brørup
Acked-by: Chengwen Feng
---
doc/guides/linux_gsg/eal_args.include.rst | 6 ++
.../prog_guide/env_abstraction_layer.rst
feature to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
Acked-by: Morten Brørup
Acked-by: Chengwen Feng
---
doc/guides/linux_gsg/eal_args.include.rst | 6 ++
.../prog_guide/env_abstraction_layer.rst
On 5/24/2022 10:40 AM, Burakov, Anatoly wrote:
On 17-May-22 4:31 PM, Don Wallwork wrote:
Add support for using hugepages for worker lcore stack memory. The
intent is to improve performance by reducing stack memory related TLB
misses and also by using memory local to the NUMA node of each
On 5/23/2022 6:35 PM, Kathleen Capella wrote:
In this section of the code:
stack_ptr = rte_zmalloc_socket("lcore_stack",
stack_size,
stack_size,
rte_lcore_to_socket_id(lcore_id));
On 5/17/2022 11:56 AM, Stephen Hemminger wrote:
On Tue, 17 May 2022 11:31:36 -0400
Don Wallwork wrote:
Add support for using hugepages for worker lcore stack memory. The
intent is to improve performance by reducing stack memory related TLB
misses and also by using memory local to the NUMA
feature to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
Acked-by: Morten Brørup
---
doc/guides/linux_gsg/eal_args.include.rst | 6 ++
.../prog_guide/env_abstraction_layer.rst | 21 +++
lib/
On 5/16/2022 4:28 PM, Stephen Hemminger wrote:
On Mon, 16 May 2022 15:50:04 -0400
Don Wallwork wrote:
+static int
+eal_parse_huge_worker_stack(const char *arg, size_t *huge_worker_stack_size)
+{
+ size_t worker_stack_size;
+ char *end;
+ if (arg == NULL || arg[0] ==
feature to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
Acked-by: Morten Brørup
---
doc/guides/linux_gsg/eal_args.include.rst | 6 ++
.../prog_guide/env_abstraction_layer.rst | 21 +++
lib/
On 5/13/2022 11:31 PM, fengchengwen wrote:
Also, this patch seem only adapt linux, what about freebsd/windows?
The intent was to add this support for this optimization for Linix only
initially. Support for other OSes can be added later. I currently
don't have a means to test the other envir
On 5/13/2022 5:38 PM, Stephen Hemminger wrote:
On Fri, 13 May 2022 13:58:22 -0400
Don Wallwork wrote:
+static int
+eal_parse_huge_worker_stack(const char *arg, size_t *huge_worker_stack_size)
+{
+ size_t worker_stack_size;
+ if (arg == NULL
ture to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
Acked-by: Morten Brørup
---
doc/guides/linux_gsg/eal_args.include.rst | 6 ++
.../prog_guide/env_abstraction_layer.rst | 21 ++
lib/
On 5/3/2022 9:08 AM, Wang, Haiyue wrote:
-Original Message-
From: Don Wallwork
Sent: Monday, May 2, 2022 22:11
To: dev@dpdk.org
Cc: d...@xsightlabs.com; step...@networkplumber.org;
m...@smartsharesystems.com; Burakov, Anatoly
; dmitry.kozl...@gmail.com; Richardson, Bruce
ture to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
---
lib/eal/common/eal_common_options.c | 31 ++
lib/eal/common/eal_internal_cfg.h | 4 ++
lib/eal/common/eal_options.h| 2 +
lib/eal/l
On 4/29/2022 3:03 PM, Stephen Hemminger wrote:
On Fri, 29 Apr 2022 14:52:03 -0400
Don Wallwork wrote:
The expectation is that use of this optional feature would be limited to cases
where the performance gains justify the implications of these tradeoffs. For
example, a specific data plane
ture to be enabled at runtime. If the size is not specified,
the system pthread stack size will be used.
Signed-off-by: Don Wallwork
---
lib/eal/common/eal_common_options.c | 26
lib/eal/common/eal_internal_cfg.h | 4 ++
lib/eal/common/eal_options.h| 2 +
lib/eal/l
On 4/27/2022 4:17 AM, Morten Brørup wrote:
+CC: EAL and Memory maintainers.
From: Don Wallwork [mailto:d...@xsightlabs.com]
Sent: Tuesday, 26 April 2022 23.26
On 4/26/2022 5:21 PM, Stephen Hemminger wrote:
On Tue, 26 Apr 2022 17:01:18 -0400
Don Wallwork wrote:
On 4/26/2022 10:58 AM
On 4/26/2022 8:42 PM, Honnappa Nagarahalli wrote:
Add support for using hugepages for worker lcore stack memory. The intent is
to improve performance by reducing stack memory related TLB misses and also
by using memory local to the NUMA node of each lcore.
This is a good idea. Have you measu
On 4/26/2022 5:21 PM, Stephen Hemminger wrote:
On Tue, 26 Apr 2022 17:01:18 -0400
Don Wallwork wrote:
On 4/26/2022 10:58 AM, Stephen Hemminger wrote:
On Tue, 26 Apr 2022 08:19:59 -0400
Don Wallwork wrote:
Add support for using hugepages for worker lcore stack memory. The
intent is
On 4/26/2022 10:58 AM, Stephen Hemminger wrote:
On Tue, 26 Apr 2022 08:19:59 -0400
Don Wallwork wrote:
Add support for using hugepages for worker lcore stack memory. The
intent is to improve performance by reducing stack memory related TLB
misses and also by using memory local to the NUMA
Add support for using hugepages for worker lcore stack memory. The
intent is to improve performance by reducing stack memory related TLB
misses and also by using memory local to the NUMA node of each lcore.
Platforms desiring to make use of this capability must enable the
associated option flag a
34 matches
Mail list logo