> > > > > > > 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/ > Thank you. rte_ring library has called out clearly if a particular file > should be included or not. If the users have included other files despite > that, may be DPDK should not be held accountable?
Agree.
