|SUCCESS| ethdev: promote experimental API's to stable

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

I'll review this patch that promotes experimental ethdev APIs to stable status.

commit <sha>
Author: Stephen Hemminger <stephen at networkplumber.org>

    ethdev: promote experimental API's to stable

[ ... ]

> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 2edc7a362e..9ba84a6e5e 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -839,7 +839,7 @@ eth_dev_validate_tx_queue(const struct rte_eth_dev *dev, uint16_t tx_queue_id)
>  	return 0;
>  }
>  
> -RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_eth_rx_queue_is_valid, 23.07)
> +RTE_EXPORT_SYMBOL(rte_eth_rx_queue_is_valid)

The RTE_EXPORT_SYMBOL() calls are missing the second argument (version)
that is required by the DPDK export mechanism. Looking at existing stable
exports in DPDK, they follow the pattern:

    RTE_EXPORT_SYMBOL(symbol_name, version)

For example, stable exports typically include a version like "25.11" or
similar. Does omitting the version argument work correctly with the
symbol versioning system? This appears in all RTE_EXPORT_SYMBOL()
conversions throughout the patch.

> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 0d8e2d0236..0381f8317a 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1061,9 +1061,6 @@ struct rte_eth_txmode {
>  };
>  
>  /**
> - * @warning
> - * @b EXPERIMENTAL: this structure may change without prior notice.
> - *
>   * A structure used to configure an Rx packet segment to split.

Does removing the experimental warning from this structure maintain ABI
compatibility? If this structure was previously experimental, did it
maintain stable size/layout throughout its experimental period? The
patch removes experimental markers from structures like
rte_eth_rxseg_split, rte_eth_rxseg, and others without verifying ABI
stability guarantees were maintained.

> @@ -2351,9 +2351,6 @@ const char *rte_eth_dev_rx_offload_name(uint64_t offload);
>  const char *rte_eth_dev_tx_offload_name(uint64_t offload);
>  
>  /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change without prior notice.
> - *
>   * Get RTE_ETH_DEV_CAPA_* flag name.
>   *
>   * @param capability
> @@ -2394,7 +2358,6 @@ const char *rte_eth_dev_tx_offload_name(uint64_t offload);
>   * @return
>   *   Capability name or 'UNKNOWN' if the flag cannot be recognized.
>   */
> -__rte_experimental

The patch removes all __rte_experimental attributes from function
declarations. According to the contribution guidelines, when promoting
APIs from experimental to stable, should there be corresponding updates
to version.map files to move symbols from EXPERIMENTAL sections to
versioned sections? The patch does not appear to include any version.map
changes.

> @@ -3447,7 +3351,6 @@ int rte_eth_xstats_get_id_by_name(uint16_t port_id, const char *xstat_name,
>   *    - (-EPERM) enabling this counter is not permitted
>   *    - (-ENOSPC) no resources
>   */
> -__rte_experimental
>  int rte_eth_xstats_set_counter(uint16_t port_id, uint64_t id, int on_off);

The rte_eth_xstats_set_counter() and rte_eth_xstats_query_state()
functions are being promoted to stable. Were these functions added in
25.03 as indicated by the RTE_EXPORT_SYMBOL changes? If so, they may be
too recent to promote in the 26.07 release according to the stated
policy of keeping APIs experimental for at least one LTS release cycle.

> @@ -6949,9 +6728,6 @@ rte_eth_tx_buffer(uint16_t port_id, uint16_t queue_id,
>  }
>  
>  /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> - *
>   * Recycle used mbufs from a transmit queue of an Ethernet device, and move
>   * these mbufs into a mbuf ring for a receive queue of an Ethernet device.
>   * This can bypass mempool path to save CPU cycles.

Does rte_eth_recycle_mbufs() have sufficient deployment and testing to
promote to stable? This is a performance-critical inline function that
directly manipulates hardware rings. Were there any behavioral changes
or bug fixes during its experimental period that might indicate the API
was still stabilizing?

> diff --git a/lib/ethdev/rte_ethdev_cman.c b/lib/ethdev/rte_ethdev_cman.c
> index a8460e6977..3a62432bf0 100644
> --- a/lib/ethdev/rte_ethdev_cman.c
> +++ b/lib/ethdev/rte_ethdev_cman.c
> @@ -12,7 +12,7 @@ 
>  #include "ethdev_trace.h"
>  
>  /* Get congestion management information for a port */
> -RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_eth_cman_info_get, 22.11)
> +RTE_EXPORT_SYMBOL(rte_eth_cman_info_get)

The congestion management APIs (rte_eth_cman_*) are being promoted from
experimental status. These were added in 22.11. Have there been any
changes to the struct rte_eth_cman_info or struct rte_eth_cman_config
layouts since 22.11? The patch should verify ABI stability was
maintained throughout the experimental period for these structures.

Does the patch need to update any corresponding entries in library
version map files to reflect the promotion of these symbols from
experimental to stable status?