[RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
Stephen Hemminger
stephen at networkplumber.org
Sun May 22 17:23:21 CEST 2022
On Sun, 22 May 2022 08:58:56 +0300
Spike Du <spiked at nvidia.com> wrote:
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8ee10..687ae5ff29 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> */
> union rte_eth_rxseg *rx_seg;
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + /**
> + * Per-queue Rx limit watermark defined as percentage of Rx queue
> + * size. If Rx queue receives traffic higher than this percentage,
> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> + */
> + uint8_t lwm;
> +
> + uint8_t reserved_bits[3];
> + uint32_t reserved_32s;
> + uint64_t reserved_64s;
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> };
>
Ok but, this is an ABI risk about this because reserved stuff was never required before.
Whenever is a reserved field is introduced the code (in this case rte_ethdev_configure).
Best practice would have been to have the code require all reserved fields be 0
in earlier releases. In this case an application is like to define a watermark
of zero; how will your code handle it.
Also, using 8 bits as percentage is different than how other API's handle this.
Since Rx queue size is in packets, why is this not in packets?
Also document what behavior of 0 is.
Why introduce new query/set operations? This should just be part of the overall
device configuration.
More information about the dev
mailing list