Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Sep 04, 2020 at 03:25:26PM +0100, Ferruh Yigit wrote:
> 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 <tangchengchang@huawei.com>
> >> Reviewed-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
> >> Acked-by: Andrew Rybchenko <arybchenko@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.

No the main concern here is to avoid the kind of ABI issues that hit the
crypto tree in a recent release. Passing the length of the array around
would actually make the regular versioning simpler (as I think we wouldn't
need to use the fancy linker versioning), but the main benefit is if that
info can be passed through to the driver layer, since driver functions
called via ethdev cannot be versioned.

/Bruce