Re: [PATCH v2] cpp: Fix missing extern "C" closing bracket

[Edvard Fagerholm <edvard.fagerholm@gmail.com>]

On Fri, Jun 27, 2025 at 6:16 PM Thomas Monjalon <thomas@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.fagerholm@gmail.com>
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
> Added root cause tracking:
> Fixes: 719834a6849e ("use C linkage where appropriate in headers")
> Cc: stable@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