Re: [PATCH v2 08/10] ethdev: add getter for per-queue Tx rate limit

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 11 Mar 2026 00:26:51 +0100
Vincent Jardin <vjardin@free.fr> wrote:

> The existing rte_eth_set_queue_rate_limit() API allows setting a
> per-queue Tx rate but provides no way to read it back. Applications
> such as grout are forced to maintain a shadow copy of the rate to
> be able to report it.
> 
> Add rte_eth_get_queue_rate_limit() as the symmetric getter, following
> the established DPDK pattern (e.g. rte_eth_dev_set_mtu/get_mtu,
> rte_eth_dev_set_vlan_offload/get_vlan_offload).
> 
> This adds:
> - eth_get_queue_rate_limit_t driver callback in ethdev_driver.h
> - rte_eth_get_queue_rate_limit() public experimental API (26.07)
> - mlx5 PMD implementation reading from the existing per-queue
>   rate_mbps tracking field
> 
> Signed-off-by: Vincent Jardin <vjardin@free.fr>

A couple of observations about this new API.

1. The queue index validation is duplicated in both ethdev and mlx5
driver. Since this is a new API, the ethdev layer should be the single place
that validates queue_idx < nb_tx_queues and rejects NULL output
pointers — the driver callbacks should be able to assume these
preconditions are met. The same applies to the existing
mlx5_set_queue_rate_limit() which re-checks bounds that
rte_eth_set_queue_rate_limit() already validates. Remove the redundant
checks from the driver.

2. The new rte_eth_get_queue_rate_limit() API uses uint32_t for the
rate. Since this is a brand-new experimental API with no backward
compatibility constraint, use uint64_t for the rate value to
accommodate future devices with rates exceeding 4 Gbps. This applies to
both the getter and the setter callback — adding a new getter that
already needs a type change next year defeats the purpose of getting
the API right now.

Surprising to me, that AI review found nits, but totally missed
several architectural issues.