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 9BBD5A0C41 for ; Sun, 7 Nov 2021 15:04:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 27E0340151; Sun, 7 Nov 2021 15:04:26 +0100 (CET) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by mails.dpdk.org (Postfix) with ESMTP id ADC1B40040 for ; Sun, 7 Nov 2021 15:04:24 +0100 (CET) Received: by mail-ot1-f42.google.com with SMTP id l7-20020a0568302b0700b0055ae988dcc8so18137533otv.12 for ; Sun, 07 Nov 2021 06:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=wu+SPP0ZfaC0a67jlLVPqgQiefNksLg8Xj741+AS4Ng=; b=At2xzRuv9VJiaCUDqDNcSU31+oFINiIwG09fd+84VVpTCIM8qomerYly1UzBwCI09T oIM4lOrJFOewcMZfaapMrwCtu+rLfo2DqqLg7ijYQxayC7ywpCKTH439xqUtiClihZzM IlQzkMd38FvDh8IjmVa4iql4EFE+irzWXQLPYQSxPhm46h95OnkXtXEDaWIUOkvI211f 1BqEapXJzn655cySu2mmH9C1eYlInNh6OBTDBocTXbOG7Z5gfhka03jUuVI5Q4nax1Bz /fv1asw/H7q9ltI8hAFJz3ZvcfzbuDq0TmlOW1YrrmoG6GgtGYst+ccGRgDUHF1PnDAF YcMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wu+SPP0ZfaC0a67jlLVPqgQiefNksLg8Xj741+AS4Ng=; b=WXXQJfg6IswYPs/cFE0fMtfaCvh1ui61SunYItCUgVhtAzHraB5me0AogG0+3vIxtD qKMhXytkyMnSTZpjzVEfp1ajeiVMJz/ND6pBLvLigXK583IsbM+Eun8sskmWpDoI0g2f g8R7T0HDjnFd4HntVFR5gbRPnNPdIYnHnw9ulYDisjBFBNpAjUB52x1duDulgialjWx3 31FT4qOXzcvl+8FF8s9w3iz/9Su4BGbcCf89Kyg7q9vBZBymxJaEiFJIKIVFKd0UYExr 2HI0yZRR0oHA1m22bdID0fKb2t/m1mbaljygF9+ovmtgzDrxrlwCVc0ZWofqSM7hQiKM NPJQ== X-Gm-Message-State: AOAM5337vG2F23/smubYuIlxOd9G+StRTwBtpu0aIeeUQnKw0XLm+mBK aCzPl2oYM8OBlvCuepuGuyaLU0zXGuiYPi4/S0QZAvd0LW3zfA== X-Google-Smtp-Source: ABdhPJyMT0yDXkwLk2yExbRd+I8IFqpOyXhDXnr2LBZZmJ0ZtrzWyA1XY3+5DiEImbCRFDDIrNzRqIwSGuEYUXoFt/k= X-Received: by 2002:a9d:7b57:: with SMTP id f23mr56383206oto.211.1636293863799; Sun, 07 Nov 2021 06:04:23 -0800 (PST) MIME-Version: 1.0 From: MOD Date: Sun, 7 Nov 2021 16:04:11 +0200 Message-ID: Subject: Difficulty with legacy mem mode DPDK 20.11 To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000080014205d0335a3e" 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 --00000000000080014205d0335a3e Content-Type: text/plain; charset="UTF-8" hi, we are in the process of upgrading to DPDK 20.11 from DPDK 17.11. We have encountered an issue where the secondary process fails to allocate it's needed memory, and have decided to use the --legacy-mem option for an easier upgrade (If there's a way to make the dynamic allocation work, we would like to hear about it as well). when starting up the application with legacy-mem, it starts to allocate resources, and then this error occurs (We are trying to allocate 256GB of 1-GB hugepages): Could not find space for memseg. Please increase 32768 and/or 65536 in configuration. This error is referring (according to the source code) to the RTE_MAX_MEMSEG_PER_TYPE and RTE_MAX_MEM_MB_PER_TYPE variables at rte_config.h We tried doing some research about them, and came up with the following: A type is page size + NUMA combination (for example, 2 NUMAs and only 2MB pages are 2 types) RTE_MAX_MEMSEG_LISTS: A memseg is a memory page, and at list one list should exists per type RTE_MAX_MEMSEG_PER_LIST and RTE_MAX_MEM_MB_PER_LIST are self explanatory RTE_MAX_MEMSEG_PER_TYPE and RTE_MAX_MEM_MB_PER_TYPE are also self explanatory changing the values according to our desired settings doesn't seem to solve the problem, so are we missing something? Thanks in advance! --00000000000080014205d0335a3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi,
we are in the process of upgrading to DPDK 20.11 f= rom DPDK 17.11. We have encountered an issue where the secondary process fa= ils to allocate it's needed memory, and have decided to use=C2=A0the --= legacy-mem option for an easier upgrade (If there's a way to make=C2=A0= the dynamic allocation work, we would like to hear about it as=C2=A0well).<= /div>
when starting up the application with legacy-mem, it starts to al= locate resources, and then this error occurs (We are trying to allocate 256= GB of 1-GB hugepages):

=C2=A0Could=C2=A0not=C2=A0f= ind=C2=A0space=C2=A0for=C2=A0memseg.=C2=A0Please=C2=A0increase=C2=A032768= =C2=A0and/or=C2=A065536=C2=A0in=C2=A0configuration.

This error is referring (according to the source code) to the=C2=A0RTE_MAX_MEMSEG_PER_TYPE= and RTE_MAX_MEM_MB_PER_TYPE variables at rte_config.h
We tried doing som= e research about=C2=A0 them, and came up with the following:

=
A type is page size=C2=A0+ NUMA combination (for example, 2 NUMA= s and only 2MB pages are 2 types)

RTE_MAX_MEMSEG_L= ISTS: A memseg is a memory page, and at list one list should exists per typ= e
RTE_MAX_MEMSEG_PER_LIST and RTE_MAX_MEM_MB_PER_LIST are self ex= planatory
RTE_MAX_MEMSEG_PER_TYPE and RTE_MAX_MEM_MB_PER_TYPE are= also self explanatory

changing the values accordi= ng to our desired settings doesn't seem to solve the problem, so are we= missing something?

Thanks in advance!
--00000000000080014205d0335a3e--