[dpdk-dev] rte_ring work

Ananyev, Konstantin konstantin.ananyev at intel.com
Fri May 8 14:57:06 CEST 2020


> > > > > Some cleanup activity (assuming above things are successful)
> > > > >
> > > > > 1) Remove the detailed comments on top of the internal functions -
> > > > > it is hard to maintain, the parameters are already
> > > > > self-explanatory
> > > > > 3) Files need some re-org
> > > > > 	a) rte_ring.h, rte_ring_hts.h, rte_ring_rts.h, rte_ring_peek.h -
> > > > > will have legacy format APIs written as wrappers around xxx_elem APIs
> > > > > 	b) rte_ring_elem.h, rte_ring_hts_elem.h, rte_ring_rts_elem.h,
> > > > rte_ring_peek_elem.h - will have xxx_elem APIs
> > > > > 	c) ring_elem_pvt.h, ring_hts_elem_pvt.h, ring_rts_elem_pvt.h,
> > > > ring_peek_elem_pvt.h
> > > > > 		- these will contain the internal functions including the c11
> > > > functions to manipulate the head/tail pointers.
> > > > > 		  The files with xxx_c11_mem.h will disappear. Make sure
> > > > private
> > > > > functions have __rte prefix
> > > >
> > > > Basically you'd plan to:
> > > > a) rename rte_ring_*_c11_mem.h  to rte_ring_*_pvt.h
> > > > b) get rid of rte_ring_generic.h
> > > > Correct?
> > > Yes
> >
> > If there would be no perf drops, I have no objections.
> Agree
> > Though recently there was a discussion is it ok to remove
> > dpdk installable headers (even ones marked as internal).
> Do you remember any conclusions? I tried to search, could not find the discussion.

http://patches.dpdk.org/patch/69560/



More information about the dev mailing list