<div dir="ltr"><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Wan Bingbing</strong> <span dir="auto"><<a href="mailto:wantmac.bingbing91@gmail.com">wantmac.bingbing91@gmail.com</a>></span><br>Date: Fri, 21 Nov 2025 at 22:15<br>Subject: Question: PMD behaviour without hugepages in DPDK 23.07 (XDP PMD in Kubernetes)<br>To:  <<a href="mailto:dev@dpdk.org">dev@dpdk.org</a>><br>Cc: <a href="mailto:chenxiemin@gmail.com">chenxiemin@gmail.com</a> <<a href="mailto:chenxiemin@gmail.com">chenxiemin@gmail.com</a>><br></div><br><br><div dir="ltr"><div>Dear DPDK team,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Given this dependency, we have the following questions:</div><div><br></div><div>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?</div><div>2.  Are there any ongoing efforts or future plans to support PMD operation in a non-hugepage mode?</div><div>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.</div><div><br></div><div>Any guidance or recommendations from the maintainers on how to proceed would be greatly appreciated.</div><div><br></div><div>Thank you for your time.</div><div><br></div><div>Best regards,</div><div>Wan Bingbing</div></div>
</div></div>