|SUCCESS| net/ena: use C11 atomic operations in platform header

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164216

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-21

I'll review this patch against the DPDK coding standards and guidelines.

---

**Commit:** From patchwork Thu May 21 04:07:07 2026

**Author:** Stephen Hemminger <stephen at networkplumber.org>

**Subject:** [PATCH] net/ena: use C11 atomic operations in platform header

**Summary:** This patch converts legacy rte_atomic32_t operations to C11
stdatomic equivalents in the ENA driver's platform header. It replaces
rte_atomic32_t and its associated functions with RTE_ATOMIC and C11
atomic operations using explicit memory ordering.

---

**Diff:**

> diff --git a/drivers/net/ena/base/ena_plat_dpdk.h b/drivers/net/ena/base/ena_plat_dpdk.h
> index c84420de22..83b354d9da 100644
> --- a/drivers/net/ena/base/ena_plat_dpdk.h
> +++ b/drivers/net/ena/base/ena_plat_dpdk.h
> @@ -40,7 +40,7 @@ typedef uint64_t dma_addr_t;
>  #endif
>  
>  #define ENA_PRIu64 PRIu64
> -#define ena_atomic32_t rte_atomic32_t
> +typedef RTE_ATOMIC(int32_t) ena_atomic32_t;

Does this change cause any ABI compatibility issues? The original
rte_atomic32_t contained a v member inside a struct. Does changing
to RTE_ATOMIC(int32_t) preserve the same size and alignment?

>  #define ena_mem_handle_t const struct rte_memzone *
>  
>  #define SZ_256 (256U)
> @@ -267,10 +267,14 @@ ena_mem_alloc_coherent(struct rte_eth_dev_data *data, size_t size,
>  #define ENA_REG_READ32(bus, reg)					       \
>  	__extension__ ({ (void)(bus); rte_read32_relaxed((reg)); })
>  
> -#define ATOMIC32_INC(i32_ptr) rte_atomic32_inc(i32_ptr)
> -#define ATOMIC32_DEC(i32_ptr) rte_atomic32_dec(i32_ptr)
> -#define ATOMIC32_SET(i32_ptr, val) rte_atomic32_set(i32_ptr, val)
> -#define ATOMIC32_READ(i32_ptr) rte_atomic32_read(i32_ptr)
> +#define ATOMIC32_INC(i32_ptr)							\
> +	rte_atomic_fetch_add_explicit((i32_ptr), 1, rte_memory_order_seq_cst)
> +#define ATOMIC32_DEC(i32_ptr)							\
> +	rte_atomic_fetch_sub_explicit((i32_ptr), 1, rte_memory_order_seq_cst)
> +#define ATOMIC32_SET(i32_ptr, val)						\
> +	rte_atomic_store_explicit((i32_ptr), (val), rte_memory_order_seq_cst)
> +#define ATOMIC32_READ(i32_ptr)							\
> +	rte_atomic_load_explicit((i32_ptr), rte_memory_order_seq_cst)

The whitespace alignment in these macro definitions uses tabs for
indentation followed by spaces for alignment. Is the spacing here
consistent with the file's existing style? The continuation backslashes
appear to be aligned further right than previously.

Does the behavior change from rte_atomic32_inc() and rte_atomic32_dec()
to rte_atomic_fetch_add_explicit() and rte_atomic_fetch_sub_explicit()
affect any code that was relying on the return value? The legacy
rte_atomic32_inc/dec return void, but fetch_add/sub return the previous
value.

>  
>  #define msleep(x) rte_delay_us(x * 1000)
>  #define udelay(x) rte_delay_us(x)