[PATCH v4 3/7] bbdev: add device info on queue topology

[Chautru, Nicolas]

Hi Tom, 

> -----Original Message-----
> From: Tom Rix <trix at redhat.com>
> Sent: Thursday, July 7, 2022 6:34 AM
> To: Chautru, Nicolas <nicolas.chautru at intel.com>; dev at dpdk.org;
> thomas at monjalon.net; gakhil at marvell.com; hemant.agrawal at nxp.com
> Cc: maxime.coquelin at redhat.com; mdr at ashroe.eu; Richardson, Bruce
> <bruce.richardson at intel.com>; david.marchand at redhat.com;
> stephen at networkplumber.org
> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
> 
> 
> On 7/6/22 2:12 PM, Chautru, Nicolas wrote:
> > Hi Tom,
> >
> >> -----Original Message-----
> >> From: Tom Rix <trix at redhat.com>
> >> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
> >>
> >>
> >> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> >>> Adding more options in the API to expose the number of queues
> >>> exposed and related priority.
> >>>
> >>> Signed-off-by: Nicolas Chautru <nicolas.chautru at intel.com>
> >>> ---
> >>>    lib/bbdev/rte_bbdev.h | 4 ++++
> >>>    1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> >>> 9b1ffa4..ac941d6 100644
> >>> --- a/lib/bbdev/rte_bbdev.h
> >>> +++ b/lib/bbdev/rte_bbdev.h
> >>> @@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
> >>>
> >>>    	/** Maximum number of queues supported by the device */
> >>>    	unsigned int max_num_queues;
> >>> +	/** Maximum number of queues supported per operation type */
> >>> +	unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> >>> +	/** Priority level supported per operation type */
> >>> +	unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> >> It is better to add new elements to the end of a structure for better
> >> backward compatibility
> > All that serie is not ABI compatible (sizes change etc...). I don’t believe there
> is such a recommendation, is there?
> 
> Depends on what users expect, a dynamically linked old application would at
> best core here.  If the elements were added to the end, yes the size would
> change but the old dynamically linked application would not use
> them.  Dynamically linking is nice because problems in the library can be fixed
> and shipped without forcing the user recompile.  Though the user may not
> realize  it, this change forces them to recompile.
> 
> Tom

Thanks Tom. In that very context, the change are big enough not to have any form of compatibility. This a new ABI version, and user knows they will have to recompile. 
Still it would be great to capture a recommendation in DPDK coding guideline in case there is such a BKM, I have heard multiple arguments for different preference, if we want to harmonize such things let's capture in coding guide lines, it would not hurt. Maybe one for Thomas?

> 
> >
> >> Tom
> >>
> >>>    	/** Queue size limit (queue size must also be power of 2) */
> >>>    	uint32_t queue_size_lim;
> >>>    	/** Set if device off-loads operation to hardware  */