DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Umakiran Godavarthi (ugodavar)" <ugodavar@cisco.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: "anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: Re: DPDK 19.11.5 Legacy Memory Design Query
Date: Fri, 23 Sep 2022 11:20:38 +0000	[thread overview]
Message-ID: <SJ0PR11MB4846972B8C726C51A8E39797DD519@SJ0PR11MB4846.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220922120052.710c2cd1@sovereign>

[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]

Hi Dmitry

My answer for your reply

You unmap memory, but you do not maintain DPDK memory management structures,
that is, DPDK does not know that this page is no longer usable.
Probably this is the reason for the crash.
You could print regions you're unmapping and the segfault address to confirm.

[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 assume 253 to 400 inside DPDK are free as we nr_pages are made by my application as 252.

ms_idx = rte_fbarray_find_next_n_free(arr, 0, 2); -> 253 comes
ms_check_idx = rte_fbarray_find_next_n_free(arr, 0, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va, msl->len), addr)/msl->page_sz); -> 253 comes (should be same as above)
ms_next_idx =  rte_fbarray_find_next_used(arr, ms_idx); -> This comes -1 as NO USED page is there (<0)

Hence we call unmap like -> munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va, msl->len), addr));

Please let us know how to check in DPDK free heaps or FBARRAY that these pages we are freeing are really safe ? (253 to 400 unwanted pages by our application, other than above 3 checks)

If it’s not safe to free, how to inform DPDK to free those pages in FBARRAY and also clean up its heap list so that it never crashes !!

We are suspecting this code below  hits NULL crash or invalid address reference for us

static struct malloc_elem *
find_suitable_element(struct malloc_heap *heap, size_t size,
                unsigned int flags, size_t align, size_t bound, bool contig)
{
        size_t idx;
        struct malloc_elem *elem, *alt_elem = NULL;

        for (idx = malloc_elem_free_list_index(size);
                        idx < RTE_HEAP_NUM_FREELISTS; idx++) {
                for (elem = LIST_FIRST(&heap->free_head[idx]);   -> We are suspecting elem is invalid address and hence crashed !!!!
                                !!elem; elem = LIST_NEXT(elem, free_list)) {
                        if (malloc_elem_can_hold(elem, size, align, bound,
                                        contig)) {
Thanks
Umakiran


From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Date: Thursday, 22 September 2022 at 2:31 PM
To: Umakiran Godavarthi (ugodavar) <ugodavar@cisco.com>
Cc: anatoly.burakov@intel.com <anatoly.burakov@intel.com>, dev@dpdk.org <dev@dpdk.org>, stephen@networkplumber.org <stephen@networkplumber.org>
Subject: Re: DPDK 19.11.5 Legacy Memory Design Query
Hi Umakiran,

> From: Umakiran Godavarthi (ugodavar) <ugodavar@cisco.com>
> 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 pages taken by DPDK process virtual memory) -> Free_HP will be 0 then, as X pages are used by DPDK and all unnecessary pages are freed in this step)
> Sample Code of 4 :
>
>               rte_memseg_list_walk_thread_unsafe(dpdk_find_and_free_unused, NULL); ->DPDK_FIND_AND_FREE_UNUSED is called for each Memory segment list (FBARRAY pointer is derived from MSL like below)
>
>               dpdk_find_and_free_unused(const struct rte_memseg_list *msl,
>                                           void *arg UNUSED)
>                {
>                       Int ms_idx;
>                        arr = (struct rte_fbarray *) &msl->memseg_arr;
>
>                         /*
>                          * use size of 2 instead of 1 to find the next free slot but
>                         * not hole.
>                         */
>                      ms_idx = rte_fbarray_find_next_n_free(arr, 0, 2);
>
>                      if (ms_idx >= 0) {
>                          addr = RTE_PTR_ADD(msl->base_va, ms_idx * msl->page_sz);
>                             munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va, msl->len), addr));
>                       }
>                }

You unmap memory, but you do not maintain DPDK memory management structures,
that is, DPDK does not know that this page is no longer usable.
Probably this is the reason for the crash.
You could print regions you're unmapping and the segfault address to confirm.

[-- Attachment #2: Type: text/html, Size: 12046 bytes --]

  reply	other threads:[~2022-09-23 11:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-14  7:30 Umakiran Godavarthi (ugodavar)
2022-09-21  6:50 ` Umakiran Godavarthi (ugodavar)
2022-09-22  8:08   ` Umakiran Godavarthi (ugodavar)
2022-09-22  9:00     ` Dmitry Kozlyuk
2022-09-23 11:20       ` Umakiran Godavarthi (ugodavar) [this message]
2022-09-23 11:47         ` Dmitry Kozlyuk
2022-09-23 12:12           ` Umakiran Godavarthi (ugodavar)
2022-09-23 13:10             ` Dmitry Kozlyuk
2022-09-26 12:55               ` Umakiran Godavarthi (ugodavar)
2022-09-26 13:06                 ` Umakiran Godavarthi (ugodavar)
2022-10-10 15:15                   ` Dmitry Kozlyuk

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=SJ0PR11MB4846972B8C726C51A8E39797DD519@SJ0PR11MB4846.namprd11.prod.outlook.com \
    --to=ugodavar@cisco.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=stephen@networkplumber.org \
    /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).