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

[Bruce Richardson]

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 at huawei.com>
> >> Reviewed-by: Wei Hu (Xavier) <xavier.huwei at huawei.com>
> >> Acked-by: Andrew Rybchenko <arybchenko at 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.

Allow me to explain a bit further. For example, we add a new field to the
end of the configuration struct or the info struct, which changes the size
of the structure. We use function versioning to allow old and new ethdev
config APIs. The new API function just works passing the structure through
to the driver API. However, the old API implementation has a problem,
because it has just been passed a structure that is too small for use by
the driver functions, so it can't just pass it along. Therefore, the code
has two choices (that I am aware of):

1. allocate a new structure of the correct size, and call the driver API
with that. Once it returns, copy the fields over to the old structure to
return to the user.
2. create a new function pointer in the ops array for legacy compatibility
and have each driver implement a function to work with the old structure.

The alternative scheme is just to pass around the structure size. The
configure ethdev API takes the pointer and size, and does not need changing
if it does not use any new fields, just passes them through to the driver
configure API. Similarly there, any drivers that don't access the new
fields don't need changing, while those that do access them just need to
check the struct size before doing so to see what version of the structure
has been received.

> 
> And I think this kind of runtime checks should be discussed for all or none
> APIs, instead of having them only for some APIs.

Yes, I agree with that.
Incidentally, this same idea was covered in the context of system calls at
the linux plumbers conf:
https://linuxplumbersconf.org/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf

Regards,
/Bruce