Re: Question: PMD behaviour without hugepages in DPDK 23.07 (XDP PMD in Kubernetes)

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Nov 21, 2025 at 10:15:39PM +0800, Wan Bingbing wrote:
>    Dear DPDK team,
>    We are currently deploying an application utilizing Seastar and DPDK
>    (version 23.07) with the XDP PMD inside a Kubernetes environment. Due
>    to infrastructure restrictions, we cannot allocate hugepages on the
>    Kubernetes nodes.
>    In this environment, DPDK fails to initialize the XDP PMD because
>    hugepage-backed memory cannot be created. Although the EAL is not
>    started with the --no-huge parameter, no hugepages are available to
>    DPDK, preventing the PMD from sending or receiving packets.
>    We are aware of the known issue documented in the DPDK release notes
>    ("PMD does not work with --no-huge EAL command line parameter"), which
>    explains that PMDs rely on hugepage-backed memory because DPDK does not
>    store the necessary physical/IOVA information for memory allocated via
>    malloc/mmap.
>    Given this dependency, we have the following questions:
>    1. Is there a currently supported method to run a hardware PMD
>    (specifically the XDP PMD) without hugepages, or is hugepage-backed
>    memory strictly required for all hardware PMDs?
>    2. Are there any ongoing efforts or future plans to support PMD
>    operation in a non-hugepage mode?
>    3. If this limitation is architectural and not planned to be addressed,
>    could you please confirm this? This confirmation would allow us to
>    evaluate alternative approaches, such as using AF_XDP without DPDK or
>    relying on the Seastar native stack.
>    Any guidance or recommendations from the maintainers on how to proceed
>    would be greatly appreciated.
>    Thank you for your time.
>    Best regards,
>    Wan Bingbing

For non-HW PMDs like the AF_XDP driver*, AFAIK it should be feasible to
have it work in no-huge mode. However, as far as I am aware, there is
nobody currently looking into this.

Regards,
/Bruce

* yes, it does use HW, but really the kernel driver does most of the work,
  so in practice its more like a SW or virtual driver.