On Fri, Jun 27, 2025 at 6:16 PM Thomas Monjalon <tho...@monjalon.net> wrote:
>
> 24/06/2025 21:58, Edvard Fagerholm:
> > RTE_FORCE_INTRINSICS with a C++ compiler causes rte_atomic.h and
> > rte_byteorder.h to emit on x86 an extern "C" without a closing
> > brace.
> >
> > Signed-off-by: Edvard Fagerholm <edvard.fagerh...@gmail.com>
> > Acked-by: Bruce Richardson <bruce.richard...@intel.com>
>
> Added root cause tracking:
> Fixes: 719834a6849e ("use C linkage where appropriate in headers")
> Cc: sta...@dpdk.org
>
> And changed the #endif comments to show the #ifndef condition is negative
> with an exclamation mark:
> #endif /* !RTE_FORCE_INTRINSICS */
>
> Applied, thanks and welcome!
>
> PS: I see you used AI to code your DPDK app, that's interesting
> and we will probably look to improve such tools in a near future.
>
> PS2: Thanks for the mobile games ;)
>LLMs do manage to create the scaffolding for a DPDK application quite well. Basically, NIC setup with different hardware accelerations is quite tedious to set up for the first time together with starting worker threads on the right cores. Since I needed to create my application for ARM and x86 the LLM produced some clearly incorrect patterns like turning RTE_FORCE_INTRINSICS on for x86 in the generated cmake file. Hence, why I ran into this bug in the first place... However, they also generated very inefficient code like updating atomic variables with stats on every packet as well as making a copy of each packet (into a malloc'd buffer). In other words, you won't be able to vibe code yourself into a very efficient application just yet. I did get all the scaffolding I needed to port an existing XDP application to DPDK in only a few days, since the XDP application's entry point is just getting the raw buffer with the packet, modifying it in-place and sending it back. This is basically what you get in DPDK too. Best, Edvard
