From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 135D5A00C3 for ; Sun, 31 Jul 2022 13:33:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 91C294067B; Sun, 31 Jul 2022 13:33:02 +0200 (CEST) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by mails.dpdk.org (Postfix) with ESMTP id 038D54021E for ; Sun, 31 Jul 2022 13:33:00 +0200 (CEST) Received: by mail-pf1-f180.google.com with SMTP id w185so8234635pfb.4 for ; Sun, 31 Jul 2022 04:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Og07fV0lMIEa2k4A4bNtbisdaU1eGXrvc+acLDnYWFY=; b=ExgDuOW06GhUJ0IOQzMlhS1l7q4tfLNoZUfF4sTto6+7azzxq2r1URF5sI6GUzXDHA PJ9IAEiMktxbzmODgY2B8ZGVTjN7e9vQxusqQtdx+BwZKIXd7F1PDO9qnBpUgycb5BqA W8YFFOAzxTLDmQUGTQYZHBNuvcegl4cdf//xBjANOSpaKbeQ9Z361Ly+aktmM0/3uDRD Q0QyX3CcPlcQ5azAecuyJ0GI8Yu7ApPKDL6WIX1sj3oReOr5KTlkOYC5LPXowmJ8pMuj pQ/Pm3hxLY+BsOGXYoOrBFoyONfz0Z+0iOnpr6p9ruWXs2uRn35W2pW3r6UYE+gXszWd I69A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Og07fV0lMIEa2k4A4bNtbisdaU1eGXrvc+acLDnYWFY=; b=MoClO/nTk2IMiHZyIa0G4NENCPMqDESOcKVxKthewhOUgVZT8Xf5IXzKs1fdS/APex vGFEZZHC8EzowHuPYQYy1/q6wfignbK9dWaHPkN6doBxHUw8hUHp7GiyCJATge5SQe3i Sq1ebjerENm8QPJlrQC98zt7g316KjbdfnhjC1wK+5hlBE8reRtzKYheYJ3RWEhNlvFm 8KUMa3+ZjMjLsT/y3HaR6+mv0iHpmhZSWXMMpAbywX9GTVWKlQiVuVJnlx9Yl8bk3P/c gpc2vUP2L0lRoIcugE6XpysGssR5YJjrzCFZ6AzZVV0TkWdAn8AgXvLr83oiM2g8FJLb bLFQ== X-Gm-Message-State: AJIora9AU0fB2bZDo6Zpk80zWhiWZvjzr/LK7LcJibXVF6kqAPyhx9dx a2r0fQMqYJI2IiSrq9wA+5HDX6+sJK+7DR17LcI= X-Google-Smtp-Source: AGRyM1v1Ncm/CKtJIy1Q4ltqYWmy2sdPkv4wQ/OlTCtez9PZYt6O0aie1bLpjpMoDITY5iKfdPMlVJNki/Xv9ptshWI= X-Received: by 2002:a65:6a0e:0:b0:41b:51b1:5be1 with SMTP id m14-20020a656a0e000000b0041b51b15be1mr9686143pgu.574.1659267180030; Sun, 31 Jul 2022 04:33:00 -0700 (PDT) MIME-Version: 1.0 References: <20220727153055.0907ea35@sovereign> <20220728161020.179f1fc7@sovereign> In-Reply-To: <20220728161020.179f1fc7@sovereign> From: MOD Date: Sun, 31 Jul 2022 14:32:47 +0300 Message-ID: Subject: Re: Mempool bigger than 1 page causes segmentation fault To: Dmitry Kozlyuk Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000da705c05e5183edc" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000da705c05e5183edc Content-Type: text/plain; charset="UTF-8" Hi, The issue is probably not with my code but with the compilation on DPDK, because I got it to repeat on a separated program, where I setup an EAL with the flags `-l 1 --no-pci` (just rte_eal_init and rte_mempool_create) this seems to be a memseg_list issue When running the program above, and requesting large amounts of memory (200M elements of 8 bytes each) I don't crash, but get `couldnt find suitable memseg_list` error This also happens when trying to allocate from the main process This error is probably related to these parameters from rte_config.h: /* EAL defines */ #define RTE_MAX_HEAPS 32 #define RTE_MAX_MEMSEG_LISTS 128 #define RTE_MAX_MEMSEG_PER_LIST 8192 #define RTE_MAX_MEM_MB_PER_LIST 32768 #define RTE_MAX_MEMSEG_PER_TYPE 32768 #define RTE_MAX_MEM_MB_PER_TYPE 65536 #define RTE_MAX_MEMZONE 2560 #define RTE_MAX_TAILQ 32 I could not find a good documentation on how to calculate the proper values for these parameters On Thu, Jul 28, 2022 at 4:10 PM Dmitry Kozlyuk wrote: > 2022-07-28 15:05 (UTC+0300), MOD: > > Hi, Thanks for the response! > > the DPDK version is 20.11.4 > > > > the stack trace is: > > malloc_elem_can_hold() // librte_eal.so.21 > > find_suitable_element() // librte_eal.so.21 > > malloc_heap_alloc() // librte_eal.so.21 > > rte_memzone_reserve_thread_safe() // librte_eal.so.21 > > rte_mempool_populate_default() // librte_mempool.so.21 > > rte_mempool_create() // librte_mempool.so.21 > > Is this all the info---no arguments, no lines? > You're using a debug build of DPDK, right? > > > RTE_MALLOC_DEBUG doesn't seem to change anything, > > but I noticed that I have been wrong about the allocation succeeding > > (not because of RTE_MALLOC_DEBUG) > > > > the error happens right on the first attempt. > > Did you try running with ASAN (meson -Db_sanitize=address)? > > Can you provide a short code to reproduce > or does it happen only in a larger program? > > Please keep Cc: users@dpdk.org so that more people can join if they want. > --000000000000da705c05e5183edc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The issue is probably not with my code but with th= e compilation on DPDK,
because I got it to repeat on a separated = program,
where I setup an EAL=C2=A0with the flags `-l 1 --no-pci`=
(just rte_eal_init and rte_mempool_create)

<= div>this seems to be a memseg_list issue
When running the program= =C2=A0 above, and requesting large amounts of memory (200M elements of 8 by= tes each)
I don't crash, but get `couldnt find suitable memse= g_list` error
This also happens=C2=A0when trying to allocate from= =C2=A0 the main process

This error is probably rel= ated to these parameters from rte_config.h:
=
/* EAL defines */
#def= ine RTE_= MAX_HEAPS 32
#define RTE_MAX_MEMSEG_LISTS 128<= /td>
#define RTE_MAX_MEMSEG_PER_LIST 8192
#define RTE_MAX_MEM_MB_PER_LIST 32768
#define RTE_MAX_MEMSEG_PER_TYPE 32768
#define RTE_MAX_MEM_MB_PER_TYPE 65536
#define = RTE_MAX_MEMZONE 2560
= #define <= span class=3D"gmail-pl-en" style=3D"box-sizing:border-box">RTE_MAX_TAILQ 32<= /td>


I could not find a good documentation on how to calculate the prop= er values for these parameters


On Thu, Jul 28, 2022 at = 4:10 PM Dmitry Kozlyuk <dmit= ry.kozliuk@gmail.com> wrote:
2022-07-28 15:05 (UTC+0300), MOD:
> Hi, Thanks for the response!
> the DPDK version is 20.11.4
>
> the stack trace is:
> malloc_elem_can_hold() // librte_eal.so.21
> find_suitable_element() // librte_eal.so.21
> malloc_heap_alloc()=C2=A0 // librte_eal.so.21
> rte_memzone_reserve_thread_safe()=C2=A0 // librte_eal.so.21
> rte_mempool_populate_default()=C2=A0 // librte_mempool.so.21
> rte_mempool_create() // librte_mempool.so.21

Is this all the info---no arguments, no lines?
You're using a debug build of DPDK, right?

> RTE_MALLOC_DEBUG doesn't seem to change anything,
> but I noticed that I have been wrong about the allocation succeeding > (not because of RTE_MALLOC_DEBUG)
>
> the error happens right on the first attempt.

Did you try running with ASAN (meson -Db_sanitize=3Daddress)?

Can you provide a short code to reproduce
or does it happen only in a larger program?

Please keep Cc: users@d= pdk.org so that more people can join if they want.
--000000000000da705c05e5183edc--