[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