> <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
[Hemant] Yes, we will submit patch to remove experimental form the fslmc bus > > 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
