2025-01-17 13:52 (UTC+), Bruce Richardson:
> The test case "test_multi_alloc_statistics" was brittle in that it did
> some allocations and frees and then checked statistics without
> considering the initial state of the malloc heaps. This meant that,
> depending on what allocations/frees were d
2024-12-31 11:45 (UTC+0300), Zaid M:
> I have an Intel CPU but I want to compile an optimized binary for AMD
> (x86_64) which may have a different CPU instruction set (e.g. avx512 or
> avx512bw) and I don't want to use "-Dplatform=generic". How can I achieve
> that?
When you use `-Dplatform=generi
MSLs
and checks that an address belongs to [`base_va`; `base_va+len`)
without checking whether `base_va == NULL` i.e. that the MSL is inactive.
Your patch also corrects `rte_mem_virt2memseg_list()` behavior.
Please mention this in the commit message.
Acked-by: Dmitry Kozlyuk
Hi Igor,
2024-10-23 02:25 (UTC+0300), Igor Gutorov:
> I've noticed an issue of `rte_memory_get_nchannel()` or
> `rte_memory_get_nrank()` always returning zero regardless of the -n or
> -r options set.
>
> I think this is due to `--in-memory` forcing `conf->no_shconf = 1`
> [1], which leads to `rt
Hi Alipour,
It looks suspicious that on the host you don't see logs about loaded drivers,
like these ones that you see inside the VM:
> 2024-12-03 19:32:36.642042 EAL: open shared lib
> /usr/lib/dpdk/pmds-24.0/librte_net_fm10k.so.24.0
> 2024-12-03 19:32:36.642266 EAL: pmd.net.fm10k.init log le
2024-11-19 15:48 (UTC+), Bruce Richardson:
> On Mon, Oct 28, 2024 at 04:26:06PM +0300, Dmitry Kozlyuk wrote:
> > 2024-10-26 06:43 (UTC-0500), Lewis Donzis:
> > > Is the extra control necessary, i.e., why not just always do this and let
> > > the EAL option co
is
> currently not supported. However, some Visual Studio environments
> default to producing 32-bit binaries.
> Recommend instructing the developer prompt to produce 64-bit binaries
> when that is the case.
>
> Signed-off-by: Andre Muezerie
Acked-by: Dmitry Kozlyuk
atus 3221226356 or signal 3221226228 SIGinvalid
> with MALLOC_PERTURB_=86
>
> Fixes: 5bce9bed67ad ("eal: add static per-lcore memory allocation facility")
>
> Reported-by: David Marchand
> Signed-off-by: Thomas Monjalon
Acked-by: Dmitry Kozlyuk
.. code-block:: console
>
> cd C:\Users\me\dpdk
It will be unclear to the reader to which machine "32-bit" refers.
Suggestion:
Building DPDK applications that run on 32-bit Windows is currently not
supported. If your Visual Studio environment defaults to producing
32-bit binaries...
With the above corrections,
Acked-by: Dmitry Kozlyuk
2024-10-26 06:43 (UTC-0500), Lewis Donzis:
> Is the extra control necessary, i.e., why not just always do this and let
> the EAL option control whether the pages get dumped?
I've been evaluating your suggestion and see no downsides,
except contigmem default behavior change, but does it have non-DP
2024-10-25 12:30 (UTC-0700), Andre Muezerie:
> -Open a 'Developer PowerShell for VS 2022' prompt from the start menu.
> +Open a 'Visual Studio Developer Command Prompt'. When doing so, it's
> recommended
> +to specify the Target Architecture (-arch) and the Host Architecture
> (-host_arch).
It s
2024-10-25 12:30 (UTC-0700), Andre Muezerie:
> Signed-off-by: Andre Muezerie
> ---
> doc/guides/windows_gsg/build_dpdk.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/guides/windows_gsg/build_dpdk.rst
> b/doc/guides/windows_gsg/build_dpdk.rst
> index c5fad81..76
From: Dmitry Kozlyuk
Hugepages often contain information useful for debugging
and thus desired for inclusion in core dumps.
However, including them has implications and drawbacks,
so it must be an opt-in at user's discretion.
This patchset add the ability to do so for FreeBSD
and for Lin
Linux excludes hugepages from core dump by default.
Describe the means to override this behavior
as well as implications of doing so.
Only mapped hugepages will be included in core dump,
because Linux EAL explicitly excludes reserved regions.
Signed-off-by: Dmitry Kozlyuk
---
doc/guides
memory.
Clear OBJ_FICTITIOUS mapping bit to include them in core dump.
Do this only if hw.contigmem.coredump_enable=1.
Signed-off-by: Dmitry Kozlyuk
---
doc/guides/freebsd_gsg/build_dpdk.rst | 27 ---
kernel/freebsd/contigmem/contigmem.c | 8
2 files changed
2024-10-24 09:38 (UTC-0700), Stephen Hemminger:
> Having a process set a system global value like coredump_filter via an
> internal
> call seems like a potential problem. What about other processes on the system?
> It may not even be allowed if using a hardened kernel.
>
> I would prefer that mad
2024-10-24 23:54 (UTC+0300), Dmitry Kozlyuk:
> 2024-10-24 09:38 (UTC-0700), Stephen Hemminger:
> > Having a process set a system global value like coredump_filter via an
> > internal
> > call seems like a potential problem. What about other processes on the
> > sys
2024-10-24 09:22 (UTC+0200), Morten Brørup:
> > From: Dmitry Kozlyuk [mailto:dmitry.kozl...@gmail.com]
> > Sent: Thursday, 24 October 2024 01.19
[...]
> > Add `--huge-dump` EAL command-line option to include in core dump
> > all mapped hugepages and also non-hugepage m
From: Dmitry Kozlyuk
Commit d72e4042c5eb ("mem: exclude unused memory from core dump")
unconditionally excluded all hugepage memory managed by DPDK.
The rationale was to avoid overly large core dumps
generated from reserved (PROT_NONE) but not mapped memory.
Mapped hugepages, however
2024-10-22 07:41 (UTC-0500), Lewis Donzis:
> I've been wondering why we exclude memory allocated by
> eal_get_virtual_area() from core dumps? (More specifically, it calls
> eal_mem_set_dump() to call madvise() to disable core dumps from the
> allocated region.)
>
> On many occasions, when debuggin
2024-10-15 16:04 (UTC-0700), Stephen Hemminger:
> This looks ok, but I know nothing about windows drivers.
> Could we get a review by Dmitry?
v3 got Reviewed-by almost a year ago, v4 only did a bit of renaming:
http://inbox.dpdk.org/dev/20231130071001.4c7931c8@sovereign/
There were no ot
2024-10-10 12:39 (UTC+0100), Bruce Richardson:
> On Thu, Oct 10, 2024 at 01:43:41PM +0300, Dmitry Kozlyuk wrote:
> > 2024-10-10 10:54 (UTC+0100), Bruce Richardson:
> > > The macros for STD*_FILENO are missing on windows. Add defines for them
> > > to t
2024-10-10 10:54 (UTC+0100), Bruce Richardson:
> The macros for STD*_FILENO are missing on windows. Add defines for them
> to the DPDK-local unistd.h file.
>
> Signed-off-by: Bruce Richardson
> ---
> lib/eal/windows/include/unistd.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff
2024-08-09 10:23 (UTC+0300), Dmitry Kozlyuk:
> 2024-08-08 12:46 (UTC-0700), Stephen Hemminger:
> > This reverts commit a089d320338d708f5b7126dab5fd6861c82e6347.
> >
> > Windows EAL should have been fixed rather than papering over
> > the bug.
>
> Linux and Free
2024-08-08 12:46 (UTC-0700), Stephen Hemminger:
> This reverts commit a089d320338d708f5b7126dab5fd6861c82e6347.
>
> Windows EAL should have been fixed rather than papering over
> the bug.
Linux and FreeBSD alarm implementations use the same approach
that limits possible timeout range in API.
Test
2024-07-29 22:18 (UTC+0530), Prashant Upadhyaya:
> Hi,
>
> I have 4 ethernet interfaces available as PCI devices.
> The PCI addresses are known.
> When I start my DPDK application, it starts up properly and assigns the
> port numbers to them as 0, 1, 2, 3 expectedly.
>
> However, is there a way I
2024-07-04 13:08 (UTC+0200), Mário Kuka:
[...]
> So I can't achieve my goal: traffic from the hairpin queues is not
> dropped if the CPU queue is overloaded.
> Any idea how to achieve this in example 4?
> What is the problem, full packet buffers/memory in the device that are
> shared between the
Hi Mário,
2024-06-19 08:45 (UTC+0200), Mário Kuka:
> Hello,
>
> I want to use hairpin queues to forward high priority traffic (such as
> LACP).
> My goal is to ensure that this traffic is not dropped in case the
> software pipeline is overwhelmed.
> But during testing with dpdk-testpmd I can't
2024-06-23 13:30 (UTC+0100), luca.bocca...@gmail.com:
> From: Luca Boccassi
>
> We now require Meson 0.53 or later, so we can use this feature introduced
> in 0.51. This also fixes a build failure on SUSE Leap 15.6.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Luca Boc
Hi Lewis,
2024-05-27 19:34 (UTC-0500), Lewis Donzis:
> I've been wondering why we exclude memory allocated by eal_get_virtual_area()
> from core dumps? (More specifically, it calls eal_mem_set_dump() to call
> madvise() to disable core dumps from the allocated region.)
>
> On many occasions, w
2024-05-13 18:37 (UTC+0300), Oleksandr Nahnybida:
[snip]
> I think ignore_msk |= last_msk; should be replaced by cur_msk &=
> last_msk; I tried this and dpdk doesn't crash anymore and seems to
> work fine, but I'd like someone else familiar with this code to take a look
> at this.
I confirm this
2024-05-05 03:25 (UTC+), Lombardo, Ed:
> Hi Dmitry,
> I tried your settings tonight and the application VIRT memory is now 7.9G and
> is in the ball park, you are amazing.
>
> #define RTE_MAX_MEMSEG_LISTS 2
> #define RTE_MAX_MEMSEG_PER_LIST 1024
> #define RTE_MAX_MEM_MB_PER_LIST 2048
> #defin
2024-05-03 23:54 (UTC+0300), Dmitry Kozlyuk:
> #define RTE_MAX_MEM_MB_PER_LIST 2024 // see item 4 below
Typo: 2048
2024-05-03 14:48 (UTC+), Lombardo, Ed:
> Hi Dmitry,
> I am not clear on the DPDK memory layout and how to tweak these #define
> values.
Given your statement:
> Currently we configure 2x1G hugepages and single socket.
I suggest the following:
#define RTE_MAX_MEMSEG_LISTS 2 // see i
Hi Ed,
I presume it's a revival of this thread:
http://inbox.dpdk.org/users/ch3pr01mb8470c9675763e14954d6e3b88f...@ch3pr01mb8470.prod.exchangelabs.com/
2024-05-02 19:05 (UTC+), Lombardo, Ed:
[...]
> My situation is as follows:
> We were on DPDK 17.11.6 and upgraded to DPDK22.11.2 to
Is "lib/eal/windows/getopt.c.orig" committed by mistake
or the license mandates storing the original code?
Acked-by: Dmitry Kozlyuk
2024-02-06 20:46 (UTC-0800), Stephen Hemminger:
> On Tue, 6 Feb 2024 17:17:31 +0100
> Mattias Rönnblom wrote:
>
> > The rte_malloc() API documentation has the following to say about the
> > align parameter:
> >
> > "If 0, the return is a pointer that is suitably aligned for any kind of
> > var
rmissions like its Unix
counterpart does. I don't insist on porting it, because this feature is not
documented and is more like a safety net.
Just making sure this is a conscious decision and not an oversight.
Acked-by: Dmitry Kozlyuk
nt.h shim compatible with MinGW
Acked-by: Dmitry Kozlyuk
2023-09-12 19:17 (UTC+0800), Ric Li:
> +virt2phys_is_valid_block(struct virt2phys_block *block, PVOID base)
Nit: "virt" would be more consistent with the rest of the code than "base".
Reviewed-by: Dmitry Kozlyuk
2023-11-24 11:09 (UTC+0100), christian.ehrha...@canonical.com:
[...]
> diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
> index 57da058cec..2f1fce3c54 100644
> --- a/lib/eal/linux/eal.c
> +++ b/lib/eal/linux/eal.c
> @@ -1067,6 +1067,16 @@ rte_eal_init(int argc, char **argv)
>
> phys_a
t;
> Fixes: 2a5d547a4a9b ("eal/windows: implement basic memory management")
>
> Cc: sta...@dpdk.org
> Signed-off-by: Gregory Etelson
Acked-by: Dmitry Kozlyuk
2023-11-14 10:22 (UTC-0800), Tyler Retzlaff:
> On Tue, Nov 14, 2023 at 08:16:22PM +0200, Etelson, Gregory wrote:
> > Hello Tyler,
> >
> > >
> > >since we are duplicating something that comes from something else that
> > >has been duplicated out of windows WDK here it might be a reasonable
> > >s
2023-11-07 23:03 (UTC+0530), rahul gupta:
> > > From: Rahul Gupta
> > > To: dev@dpdk.org, tho...@monjalon.net
> > > Cc: sovar...@linux.microsoft.com, ok...@kernel.org,
> > sujithsan...@microsoft.com, sowmini.varad...@microsoft.com,
> > rahulrgupt...@gmail.com, Rahul Gupta , Rahul
> > Gupta
2023-09-22 16:12 (UTC+0800), Fengnan Chang:
> ping
>
> Fengnan Chang 于2023年9月12日周二 17:05写道：
> >
> > Let's look at this path:
> > malloc_elem_free
> >->malloc_elem_join_adjacent_free
> > ->join_elem(elem, elem->next)
> >
> > 0. cur elem's pad > 0
> > 1. data area memset in malloc_ele
2023-09-12 11:13 (UTC+), Li, Ming3:
> > Is any if these bugs are related?
> > If so, please mention "Bugzilla ID: " in the commit message.
> >
> > https://bugs.dpdk.org/show_bug.cgi?id=1201
> > https://bugs.dpdk.org/show_bug.cgi?id=1213
> >
>
> Sure, will do.
>
> I cannot reproduce th
Hi Ric,
2023-09-11 21:09 (UTC+0800), Ric Li:
> The virt2phys_translate function previously scanned existing blocks,
> returning the physical address from the stored MDL info if present.
> This method was problematic when a virtual address pointed to a freed
> and reallocated memory segment, potent
otplug_lock is taken in rte_eal_init(), so it's
> + * safe to call thread-unsafe version.
> + */
Nit: the lock is really taken in rte_eal_memory_init().
Probably "The lock is held during initialization, so..."
would more robust against code changes and differences between platforms.
Acked-by: Dmitry Kozlyuk
2023-08-30 13:33 (UTC+0300), Artemy Kovalyov:
> Following these changes, the RW-lock no longer supports
> recursion, implying that a single thread shouldn't obtain a read lock if
> it already possesses one. The problem arises during initialization: the
> rte_eal_init() function acquires the memory_
2023-08-14 09:27 (UTC+0100), Bruce Richardson:
> On Fri, Aug 11, 2023 at 11:24:44AM -0700, Tyler Retzlaff wrote:
> > Detect when MSVC toolset is available and tweak toolchain arguments
> > where the meson build system offers no abstraction.
> >
> > Signed-off-by: Tyler Retzlaff
> > Acked-by: Bruc
2023-08-09 08:34 (UTC-0700), Stephen Hemminger:
> On Tue, 8 Aug 2023 16:23:43 -0700
> Tyler Retzlaff wrote:
>
> > >
> > > bpf: not built on Windows. Needs some libelf.
> > > pdump: not built on Windows. Needs bpf for filtering
>
> A different topic, is it possible to get pdump working on Wind
2023-08-02 15:41 (UTC-0700), Tyler Retzlaff:
> one thing that confuses me a little and this change won't break how the
> code already works (just makes the cast redundant) is that for mingw
> sizeof(long) is being reported as 8 bytes.
>
> this is in spec relative to the C standard but it does leav
the expression should safely fit in the long.
>
> Signed-off-by: Tyler Retzlaff
> ---
> lib/eal/windows/include/rte_os_shim.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Dmitry Kozlyuk
.
Remove the call to rte_srand() at sketch creation.
Document that hash seeds are not used by SKETCH set summary type.
Fixes: db354bd2e1f8 ("member: add NitroSketch mode")
Cc: leyi.r...@intel.com
Signed-off-by: Dmitry Kozlyuk
---
lib/member/rte_member.h| 1 +
Hi,
2023-06-14 11:48 (UTC+0100), Ferruh Yigit:
> Also @Dmitry, is there solution for Windows for this issue (a tool to
> replace cpu_layout.py)?
hwloc binaries, including lstopo-no-graphics.exe,
are packaged for Windows by the authors:
https://www.open-mpi.org/software/hwloc/current/
Hi,
2023-04-12 08:44 (UTC+), wuchangsheng (C):
> When using rte_malloc and rte_free to request and release memory repeatedly,
> the usage of large pages gradually increases.
Do you have a repro?
> Checking the relevant source code shows that memory requests and releases
> are started from t
2023-04-05 08:25 (UTC-0700), Tyler Retzlaff:
> On Wed, Apr 05, 2023 at 09:54:46AM +0100, Bruce Richardson wrote:
> > On Tue, Apr 04, 2023 at 06:04:32PM -0700, Stephen Hemminger wrote:
> > > On Tue, 4 Apr 2023 09:47:21 +0100
> > > Bruce Richardson wrote:
> > >
> > > > My suggestion is to use a
On Tue, Apr 4, 2023 at 3:49 PM David Marchand wrote:
>
> This code uses locks to implement synchronisation between two threads.
> There seems nothing wrong with it, just silence the clang lock check.
>
> Signed-off-by: David Marchand
Acked-by: Dmitry Kozlyuk
2023-03-30 14:28 (UTC+0100), Bruce Richardson:
> On Thu, Mar 30, 2023 at 02:15:42PM +0100, Bruce Richardson wrote:
> > On Thu, Mar 30, 2023 at 02:53:41PM +0200, Christian Ehrhardt wrote:
> > > Hi,
> > > I've recently gotten a kind of bug I was waiting for many years.
> > > In fact I wondered if i
2023-03-23 13:13 (UTC+), Ferruh Yigit:
> On 6/6/2022 8:53 AM, Michał Krawczyk wrote:
> > sob., 21 maj 2022 o 00:08 Ferruh Yigit napisał(a):
> >>
> >> On 8/30/2021 3:05 PM, William Tu wrote:
> >>> On Mon, Aug 30, 2021 at 12:12 AM Michał Krawczyk
> >>> wrote:
> >>> [...]
> Hi Willia
On Thu, Mar 16, 2023 at 4:11 AM fengchengwen wrote:
> Because we have no API to know the PMD whether impl specific ops, we could
> only knowed by invoking.
> Except above impl, I also consider the other two:
> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private
> info")
l needed in rte_eth_ring.h
to avoid the fatal warning about `strdup()` with clang (MS CRT, actually).
For the series,
Acked-by: Dmitry Kozlyuk
2023-02-01 14:54 (UTC+), Arseniy Aharonov:
> This method can't work in Windows with MSVC (at least to the best of my
> knowledge).
In Windows generally, not limited to MSVC.
> How does DPDK solve if in Windows for MSVC? I failed to find the answer.
It just doesn't.
Fortunately, symbol ver
2023-01-30 11:23 (UTC+0200), Ophir Munk:
> In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> coded as 2560. For applications requiring different values of this
> parameter – it is more convenient to set its value as part of the meson
> command line or to set the max value vi
2023-01-12 21:37 (UTC+0100), Thomas Monjalon:
> The vector Rx functions are conditionally compiled.
> Some stub functions were also always compiled with weak attribute.
> If there is no vector support, the weak functions were linked.
>
> These weak functions are moved in a specific file
> which is
DAC_READ_SEARCH or DAC_OVERRIDE capability is required to access
/proc/self/pagemap, but the Linux guide mentioned neither one.
Recommend DAC_READ_SEARCH as less impactful.
Fixes: 979bb5d493fb ("doc: add more instructions for running as non-root")
Cc: sta...@dpdk.org
Signed-off-
2023-01-14 18:27 (UTC-0800), Stephen Hemminger:
> DAC_OVERRIDE is like having the master key. It opens all doors
> and if so, running as non-root really doesn't matter that much.
>
> Ideally, a finer grain permission could be used.
> Recommending this to users seems wrong.
According to my tests,
CAP_DAC_OVERRIDE capability is required to access /proc/self/pagemap,
but it was missing from the Linux guide, causing issues for users.
Fixes: 979bb5d493fb ("doc: add more instructions for running as non-root")
Cc: sta...@dpdk.org
Signed-off-by: Dmitry Kozlyuk
Reported-by: Boris
by ensuring any matched mount point is either an
> exact match or a parent path of --huge-dir.
>
> Fixes: 24d5a1ce6b85 ("eal/linux: allow hugetlbfs sub-directories")
> Cc: john.le...@nutanix.com
> Cc: sta...@dpdk.org
> Signed-off-by: Ashish Sadanandan
Acked-by: Dmitry
2022-12-15 09:48 (UTC-0800), Tyler Retzlaff:
> On Wed, Dec 14, 2022 at 07:22:15PM -0800, Stephen Hemminger wrote:
> > On Wed, 14 Dec 2022 15:18:08 -0800
> > "Kadam, Pallavi" wrote:
[...]
> > > There is still a build error with clang compiler on Windows
> > > as mentioned by Dmitry:
> > >
> > > ..
2022-12-13 11:43 (UTC-0500), Sinan Kaya:
> Checking to see if I need to cover any feedback.
There was some feedback to pre-resend v2 that is not visible on patchwork:
http://inbox.dpdk.org/dev/cajfav8yee9awya3ovluqavfw0mzonsqjq-k+2q4wampmyrj...@mail.gmail.com/
2022-11-21 17:32 (UTC-0500), ok...@kernel.org:
> From: Sinan Kaya
>
> In malloc_heap_free result of call to malloc_elem_free is dereferenced
> here and may be null.
It may not: "malloc_elem_free()" never returns NULL by definition:
it takes a valid busy element and returns a valid free element.
2022-11-21 17:32 (UTC-0500), ok...@kernel.org:
> From: Sinan Kaya
>
> In malloc_elem_find_max_iova_contig result of call to rte_mem_virt2memseg
> is dereferenced here and may be null.
>
> Signed-off-by: Sinan Kaya
> ---
> lib/eal/common/malloc_elem.c | 11 ---
> lib/eal/common/malloc_h
2022-11-21 17:32 (UTC-0500), ok...@kernel.org:
> From: Sinan Kaya
>
> In eal_memalloc_is_contig result of call to rte_fbarray_get
> is dereferenced here and may be null.
>
> Signed-off-by: Sinan Kaya
> ---
> lib/eal/common/eal_common_memalloc.c | 5 -
> 1 file changed, 4 insertions(+), 1 d
2022-11-21 17:32 (UTC-0500), ok...@kernel.org:
> From: Sinan Kaya
>
> In alloc_pages_on_heap result of call to rte_mem_virt2memseg_list
> is dereferenced here and may be null.
>
> Signed-off-by: Sinan Kaya
> ---
> lib/eal/common/malloc_heap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
2022-11-21 17:32 (UTC-0500), ok...@kernel.org:
> From: Sinan Kaya
>
> In malloc_heap_add_memory result of call to malloc_elem_join_adjacent_free
> is dereferenced here and may be null.
It may not:
"malloc_elem_join_adjacent_free()" never returns NULL by definition.
Would annotating "malloc_elem_
2022-11-21 17:32 (UTC-0500), ok...@kernel.org:
> From: Sinan Kaya
>
> In memzone_reserve_aligned_thread_unsafe result of call
> to malloc_elem_from_data is dereferenced here and may be null.
>
> Signed-off-by: Sinan Kaya
Acked-by: Dmitry Kozlyuk
Hi Amit,
2022-10-21 19:26 (UTC+), Amit Prakash Shukla:
[...]
> > How does the user learn heap_id?
> > There probably should be /eal/heap_id returning a list of heap IDs.
>
> Request for list of active heap Id's is already present.
> " /eal/heap_list"
My bad!
> > > --> /eal/element_list,0
2022-10-11 07:10 (UTC+), Amit Prakash Shukla:
> Thanks David for the feedback. Please find the proposed fixed inline.
>
> > -Original Message-
> > From: David Marchand
> > Sent: Saturday, October 8, 2022 1:17 AM
> > To: Amit Prakash Shukla ; Thomas Monjalon
> > ; Anatoly Burakov ;
> >
2022-09-29 17:13 (UTC+0530), Amit Prakash Shukla:
> Changes adds telemetry support to display memory occupancy
> in memseg and the information of the elements allocated from
> a memseg based on arguments provided by user. This patch
> adds following endpoints:
>
> 1. /eal/memseg_list_array
> The c
2022-10-20 15:12 (UTC+0500), Huzaifa Rahman:
> On Thu, Oct 6, 2022 at 3:42 PM Dmitry Kozlyuk
> wrote:
>
> > 2022-10-06 10:04 (UTC+), huzaifa.rahman:
> > > Bugzilla ID: 560
> > >
> > > The memory subsystem is leaving open a file descriptor fo
2022-10-11 12:17 (UTC+), Chengwen Feng:
> This patch adds memarea to malloc_perf_autotest.
>
> Test platform: Kunpeng920
> Test command: dpdk-test -a :7d:00.3 -l 10-12
> Test result:
> USER1: Performance: rte_memarea
> USER1:Size (B) Runs Alloc (us) Free (us) Total (us) memset (us)
2022-10-11 12:17 (UTC+), Chengwen Feng:
> This patch adds a memarea backup mechanism, where an allocation request
> which cannot be met by the current memarea is deferred to its backup
> memarea.
This is a controversial feature.
1. It violates memarea property of freeing all allocated objects
2022-10-11 12:17 (UTC+), Chengwen Feng:
> This patch supports rte_memarea_alloc()/rte_memarea_free()/
> rte_memarea_update_refcnt() API.
>
> Signed-off-by: Chengwen Feng
> ---
> doc/guides/prog_guide/memarea_lib.rst | 10 ++
> lib/memarea/memarea_private.h | 3 +
> lib/memarea/rte
2022-10-11 12:17 (UTC+), Chengwen Feng:
[...]
> diff --git a/doc/guides/prog_guide/memarea_lib.rst
> b/doc/guides/prog_guide/memarea_lib.rst
> new file mode 100644
> index 00..85ad57145f
> --- /dev/null
> +++ b/doc/guides/prog_guide/memarea_lib.rst
> @@ -0,0 +1,39 @@
> +.. SPDX-Licens
static memory layout.
In dynamic memory mode, it would be useless, because unneeded pages
are not allocated in the first place and freed once not used anymore.
[1]: https://core.dpdk.org/roadmap/#stable
> From: Umakiran Godavarthi (ugodavar)
> Date: Monday, 26 September 2022 at
2022-10-06 10:04 (UTC+), huzaifa.rahman:
> Bugzilla ID: 560
>
> The memory subsystem is leaving open a file descriptor for each
> rtemap file. This can lead to hundreds of extra open file descriptors
> which has negative side effects. For example, the application may go
> over its maximum file
2022-09-23 12:12 (UTC+), Umakiran Godavarthi (ugodavar):
> [Uma] : Yes I agree if free_hp = 400, nr_hp = 252, we are expecting DPDK
> takes only 252 and keep the remaining pages free in its heap.
>As you have mentioned just boot DPDK with 1 page, and add
> pages we want late
2022-09-23 11:20 (UTC+), Umakiran Godavarthi (ugodavar):
> [Uma] : Yes we are unmapping the entire range hoping all are free inside
> DPDK and DPDK heaps never use these pages.
>
> Suppose we have 400 pages total free_hp, we want only 252 pages , so we
> reduce nr_pages to 252.
>
> So we
Hi Umakiran,
> From: Umakiran Godavarthi (ugodavar)
> Date: Wednesday, 14 September 2022 at 1:00 PM
[...]
> 1. Then we go to DPDK Memory segment list walkthrough and for each FBARRAY
> , we find the used pages by DPDK and unmap the remaining pages by below code
> (Idea is to free the huge pa
> From: Dmitry Kozlyuk
> Sent: Monday, August 8, 2022 12:43 PM
> To: dev@dpdk.org
> Cc: Olivier Matz ; Andrew Rybchenko
> ; sta...@dpdk.org
> Subject: [PATCH 1/2] mempool: make event callbacks process-private
>
> Callbacks for mempool events were registered in a process-
2022-09-21 15:35 (UTC+0200), David Marchand:
> On Thu, Jul 28, 2022 at 8:03 PM Dmitry Kozlyuk
> wrote:
> >
> > 2022-07-28 14:41 (UTC+0500), Fidaullah Noonari:
> > > The amount of memory to allocate from the system for heap expansion
> > > was calculated i
2022-09-20 14:30 (UTC+0300), Dmitry Kozlyuk:
> 2022-09-20 03:46 (UTC+), Chengwen Feng:
> > The memarea library is an allocator of variable-size object. It is a
> > collection of allocated objects that can be efficiently alloc or free
> > all at once, the main features are
2022-09-20 03:46 (UTC+), Chengwen Feng:
> The memarea library is an allocator of variable-size object. It is a
> collection of allocated objects that can be efficiently alloc or free
> all at once, the main features are as follows:
> a) it facilitate alloc and free of memory with low overhead.
>
> Note:
> a) the memarea is oriented towards the application layer, which could
> provides 'region-based memory management' [1] function.
>
Judging from the API, this library would rather provide
an interface to a generic allocator over a fixed memory extent,
because it offers freeing of specifi
Thank you for the most detailed info!
1. If you run the poisoner program the second time,
does it also see dirty memory immediately after mmap()?
2. Kernel 4.19.90-2102 patchlevel 2102 is very high,
can there be any unusual patches applied?
Your host has "compute" in its name,
can it
2022-08-29 14:37 (UTC+0200), Morten Brørup:
> > From: David Marchand [mailto:david.march...@redhat.com]
> > Sent: Monday, 29 August 2022 13.58
> >
> > > > > > On Sat, Aug 27, 2022 at 12:57:50PM +0300, Dmitry Kozlyuk wrote:
> > > > > > >
2022-08-27 13:31 (UTC+), lic121:
> On Sat, Aug 27, 2022 at 12:57:50PM +0300, Dmitry Kozlyuk wrote:
> > 2022-08-27 09:25 (UTC+), chengt...@qq.com:
> > > From: lic121
> > >
> > > When RTE_MALLOC_DEBUG not configured, rte_zmalloc_socket() doens't
Do not include , , and from ,
because they are not used by this file.
Include the needed headers directly from the files that need them.
Signed-off-by: Dmitry Kozlyuk
---
app/test-bbdev/main.c| 1 +
app/test-bbdev/test_bbdev_perf.c
There is no reason for rte_str_to_size() to be inline.
Move the implementation out of .
Export it as a stable ABI because it always has been public.
Signed-off-by: Dmitry Kozlyuk
Acked-by: Morten Brørup
Acked-by: Bruce Richardson
Acked-by: Chengwen Feng
---
lib/eal/common
1 - 100 of 1024 matches
Mail list logo
