On Wed, 11 Mar 2026 00:26:51 +0100 Vincent Jardin <[email protected]> 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 <[email protected]> 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.
