On 1/8/2020 1:00 PM, David Marchand wrote: > On Wed, Jan 8, 2020 at 1:30 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote: >> On 1/8/2020 9:55 AM, David Marchand wrote: >>> On Wed, Jan 8, 2020 at 10:09 AM Ferruh Yigit <ferruh.yi...@intel.com> wrote: >>>> Why it is an ABI break, dev_ops should be between library and drivers, so >>>> it >>>> should be out of the ABI concern, isn't it. >>> >>> You are right. >>> So in our context, this is not an ABI breakage. >>> But abidiff still reports it, so maybe some filtering is required to >>> avoid this false positive. >>> >>> Note that if we insert an ops before rx_queue_count, we would have a >>> real ABI breakage, as this ops is accessed via an inline wrapper by >>> applications. >>> >> >> This is good point, perhaps we should add a comment to that line to >> highlight it. > > The comment won't help in the CI checks. > > > Not talking about short term, but could we consider separating the > inlined ops from the rest (pushing them to rte_eth_dev ?) ? > We would then hide completely eth_dev_ops at the next ABI break window.
+1 We didn't able to apply the patch that removes the inline functions [1] because of the performance concerns, but at least separating some ops enables us to hide the eth_dev_ops, although I guess still have to expose 'rte_eth_dev' & 'rte_eth_dev_data'. Still better than nothing. [1] https://patches.dpdk.org/patch/58874/
