[dpdk-dev] DPDK Experimental Functions
Honnappa Nagarahalli
Honnappa.Nagarahalli at arm.com
Fri Sep 4 06:48:55 CEST 2020
<snip>
>
> Hi All,
>
> During recent work on the DPDK ABI, where we are looking to develop a
> nightly ABI regression test.
>
> We found a large number of experimental functions currently in DPDK API.
> Currently, there are 537 experimental APIs out of a total of roughly ~1800
> API, 30%-ish.
>
> While there is no correct number, as a percentage of the total, this appears
> to be very high.
> I would question if all these API are really "new" and warrant the status?
>
> There are currently 38 libraries and drivers with experimental functions.
> And to be fair there are number of recently added libraries in list, shown
> below.
> However there are also a number of libraries that have been around a very
> long time.
>
> The following libraries and drivers have 10 or more experimental functions:
>
> 1. rte_eal: 119
We are ready to remove the tag for ticket lock and MCS lock APIs.
> 2. rte_ethdev: 43
> 3. rte_vhost: 42
> 4. rte_graph: 35 (EXPERIMENTAL)
> 5. rte_compressdev: 34
> 6. rte_rib: 28 (EXPERIMENTAL)
> 7. rte_pipeline: 24
> 8. rte_regexdev: 22 (EXPERIMENTAL)
> 9. rte_cryptodev: 18
> 10. rte_fib: 16 (EXPERIMENTAL)
> 11. rte_ipsec: 15 (EXPERIMENTAL)
> 12. rte_telemetry: 12 (EXPERIMENTAL)
> 13. rte_mbuf: 11
> 14. rte_rcu: 11 (EXPERIMENTAL)
I am ready to remove experimental status for the base RCU APIs. I would wait for defer queue APIs for another release as I am expecting integration into few more libraries. That would leave 4 APIs experimental still.
> 15. rte_bus_fslmc: 11
> 16. rte_bpf: 10 (EXPERIMENTAL)
>
> Do the maintainers of these libraries and drivers, A. Feel that experimental
> status continues to be warranted against these API?
> B. Have plans in place to move all/some of these functions to stable in the
> 20.11 timeframe?
>
> Kudos to Conor Walsh for pulling this data together.
>
> Thanks,
>
> Ray K
More information about the dev
mailing list