[dpdk-dev] DPDK Experimental Functions

[Hemant Agrawal]

> <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