On 9/3/2020 4:35 PM, Bruce Richardson wrote:
> On Sat, Aug 29, 2020 at 03:13:16PM +0800, Chengchang Tang wrote:
>> Add a field named rx_buf_size in rte_eth_rxq_info to indicate the buffer
>> size used in receiving packets for HW.
>>
>> In this way, upper-layer users can get this information by calling
>> rte_eth_rx_queue_info_get.
>>
>> Signed-off-by: Chengchang Tang <tangchengch...@huawei.com>
>> Reviewed-by: Wei Hu (Xavier) <xavier.hu...@huawei.com>
>> Acked-by: Andrew Rybchenko <arybche...@solarflare.com>
>> ---
>> lib/librte_ethdev/rte_ethdev.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index 70295d7..9fed5cb 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info {
>> struct rte_eth_rxconf conf; /**< queue config parameters. */
>> uint8_t scattered_rx; /**< scattered packets RX supported. */
>> uint16_t nb_desc; /**< configured number of RXDs. */
>> + /**< buffer size used for hardware when receive packets. */
>> + uint16_t rx_buf_size;
>> } __rte_cache_min_aligned;
>>
> Since this is breaking the ABI, this looks like the perfect opportunity to
> add in a qinfo_size parameter to rte_eth_rx_queue_info_get() call which
> allows ABI sanity-checking. Also, if passed through to the individual
> drivers, allows them to make ABI determinations since driver functions
> cannot be versioned, i.e. the driver info function cannot know whether it
> has been called by queue_info_v21 or queue_info_v22.
>
Current approach we have is to detect the ABI breakage before release and either
block it or use ABI versioning.
What you suggest to add runtime checks assumes application can call old and new
APIs, which is not our case and not sure what this runtime check adds.
The option to use runtime check between library and driver can be needed if
library and driver from different DPDK versions can be used together, I think
enabling this can bring more complexity and better to use all components of a
DPDK release together.
And I think this kind of runtime checks should be discussed for all or none
APIs, instead of having them only for some APIs.
