DPDK patches and discussions
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "mannywang(王永峰)" <mannywang@tencent.com>, dev <dev@dpdk.org>
Cc: konstantin.v.ananyev <konstantin.v.ananyev@yandex.ru>
Subject: RE: [RFC] rte_acl_build memory fragmentation concern and proposal for external memory support
Date: Mon, 17 Nov 2025 12:51:01 +0000	[thread overview]
Message-ID: <66734dfb22e841ddad035c630bb74f1c@huawei.com> (raw)
In-Reply-To: <tencent_4125B1322F9238892BFA5F38@qq.com>

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

Hi,
I suppose you mean some sort of user-provided alloc()/free() callbacks that
will be used by ACL lib at generate phase?
And I presume if none provided, by default it will fall-back to rte_malloc/rte_free?
If so, then yes, sounds reasonable.
Patches are welcomed :)
Konstantin

From: mannywang(王永峰) <mannywang@tencent.com>
Sent: Friday, November 14, 2025 2:52 AM
To: dev <dev@dpdk.org>
Cc: konstantin.v.ananyev <konstantin.v.ananyev@yandex.ru>
Subject: [RFC] rte_acl_build memory fragmentation concern and proposal for external memory support

Problem Statement

Hello DPDK community,

We've been using DPDK's ACL library in a long-running network application and observed a concerning issue regarding memory fragmentation. The rte_acl_build()function internally uses rte_zmalloc_socket()for dynamic memory allocation during ACL rule compilation.

While this design works well for short-lived processes, it creates challenges for long-running applications (days/weeks) where memory fragmentation becomes a critical concern. Each ACL rebuild (due to rule updates, configuration changes, etc.) allocates variable-sized memory blocks for the trie structures and transition tables, which are then freed when the ACL context is destroyed or rebuilt.

This pattern leads to:
1.  Memory fragmentation​ over time, as the heap accumulates "holes" of varying sizes
2.  Potential allocation failures​ even when total free memory appears sufficient
3.  Difficulty in memory budgeting for deterministic systems
Current Limitation

The current API doesn't allow applications to provide pre-allocated memory for ACL construction, forcing dynamic allocations that contribute to heap fragmentation. This is particularly problematic for applications that prioritize long-term stability and predictable memory usage.

Proposed Solution

We propose extending the ACL API to support external memory buffers for the build process. This would allow applications to manage memory allocation strategies according to their specific requirements (pool-based, static allocation, etc.).

________________________________
发自我的企业微信<https://work.weixin.qq.com/wework_admin/user/h5/qqmail_user_card/vc879305fe5b6b5af3?from=myprofile>



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

      reply	other threads:[~2025-11-17 12:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14  2:51 mannywang(王永峰)
2025-11-17 12:51 ` Konstantin Ananyev [this message]

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=66734dfb22e841ddad035c630bb74f1c@huawei.com \
    --to=konstantin.ananyev@huawei.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=mannywang@tencent.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).