DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Lombardo, Ed" <Ed.Lombardo@netscout.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: RE: Need help with reducing VIRT memory
Date: Fri, 3 May 2024 14:48:12 +0000	[thread overview]
Message-ID: <CH3PR01MB8470E906BEAD84329B81818C8F1F2@CH3PR01MB8470.prod.exchangelabs.com> (raw)
In-Reply-To: <CH3PR01MB84706C3E357630120BA6891C8F182@CH3PR01MB8470.prod.exchangelabs.com>

Hi Dmitry,
I am not clear on the DPDK memory layout and how to tweak these #define values.  

#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

I want to limit how much DPDK grabs for memory, but grabs what it absolutely needs for our application.  I don't want DPDK to plan for any hot-plug or dynamic adjustments of hugepages.  Our configuration is static, we allocate hugepages, discover ports and initialize couple ring buffers and 1 Rx Q and 4 Tx Qs per port.  Max of 4 ports.
My goal is to reduce our application VIRT memory by 80%.  Not clear which config variables to adjust.

What do you suggest, is there a formula?

Regards,
Ed


-----Original Message-----
From: Lombardo, Ed 
Sent: Thursday, May 2, 2024 4:59 PM
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: dev@dpdk.org
Subject: RE: Need help with reducing VIRT memory

Hi Dmitry,
Yes.  I will look into 

The VM gives the following:
[root@vSTREAMO9-234 bin]# prlimit -v
RESOURCE DESCRIPTION              SOFT      	HARD		 UNITS
AS       	address space limit 	unlimited 	unlimited	 bytes

I saw these optional configurations in my google searching, but was hesitant because of unknown impact.  I will try this path next.

It would be valuable to have meson be able to configure DPDK for low memory devices.

Thank you for replying.

Regards,
Ed

-----Original Message-----
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Sent: Thursday, May 2, 2024 4:04 PM
To: Lombardo, Ed <Ed.Lombardo@netscout.com>
Cc: dev@dpdk.org
Subject: Re: Need help with reducing VIRT memory

External Email: This message originated outside of NETSCOUT. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Ed,

I presume it's a revival of this thread:

	https://urldefense.com/v3/__http://inbox.dpdk.org/users/CH3PR01MB8470C9675763E14954D6E3B88F292@CH3PR01MB8470.prod.exchangelabs.com/__;!!Nzg7nt7_!EBENSvDUv9LcvbAw6vLkHgh11JdjksApffakP2JU30OJaPLCkZPZVzk4U8rRTJsxJVCeRubpFQy7TB2-R6jDbrk4QpU$ 

2024-05-02 19:05 (UTC+0000), Lombardo, Ed:
[...]
> My situation is as follows:
> We were on DPDK 17.11.6 and upgraded to DPDK22.11.2 to support the Intel E810.  Also upgraded from CentOS7 to Oracle 91.
> In DPDK 22.11.2 the VIRT memory has skyrocketed and causes major issues with our application that runs on 16 GB of memory (virtual appliances and low end remote appliances).
> 
> I have also tried DPDK 23.11 and 24.03 and I also see across the DPDK 
> versions that the VIRT memory has increase by a factor of 5 over DPDK
> 17.11
> 
> Our application process shows VIRT memory is 7.6 GB with DPDK 17.11.6, 
> and with DPDK 22.11.2, 23.11.2 and 24.03 the VIRT memory is ~36.6GB
> 
> Our application minimum configuration needs to run with 16 GB memory when DPDK is enabled.

As explained in the linked thread,
high reserved VIRT does not mean high memory demand.
Running DPDK on a 16 GB machine is perfectly viable.
Something in your app or setup conflicts with the high VIRT reservation.

> Our application uses memory locking and rlimit settings to get optimal performance.

Does it use address space limit (prlimit -v)?
If so, this limit may be hit.
With default build options, DPDK reserves at least 32 GB of VIRT (one list) per memory type (a combination of NUMA node + hugepage size).
This is controlled by defines in <rte_config.h>:

#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

Try reducing those and rebuilding DPDK if the above is your case.
Reducing these values will limit the amount of memory available to DPDK allocator in your app.

  reply	other threads:[~2024-05-03 14:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-02 19:05 Lombardo, Ed
2024-05-02 20:03 ` Dmitry Kozlyuk
2024-05-02 20:58   ` Lombardo, Ed
2024-05-03 14:48     ` Lombardo, Ed [this message]
2024-05-03 15:27       ` Bruce Richardson
2024-05-03 15:52         ` Bruce Richardson
2024-05-03 18:58           ` Morten Brørup
2024-05-03 20:07             ` Lombardo, Ed
2024-05-03 20:54       ` Dmitry Kozlyuk
2024-05-03 20:56         ` Dmitry Kozlyuk
2024-05-03 21:18           ` Lombardo, Ed
2024-05-04  6:51             ` Morten Brørup
2024-05-05  3:25           ` Lombardo, Ed
2024-05-05  9:35             ` 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=CH3PR01MB8470E906BEAD84329B81818C8F1F2@CH3PR01MB8470.prod.exchangelabs.com \
    --to=ed.lombardo@netscout.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    /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).