> -----Original Message----- > From: Pavan Nikhilesh Bhagavatula > [mailto:pbhagavat...@caviumnetworks.com] > Sent: Tuesday, December 12, 2017 2:18 AM > To: Eads, Gage <gage.e...@intel.com>; > jerin.jacobkollanukka...@cavium.com; Van Haaren, Harry > <harry.van.haa...@intel.com>; Rao, Nikhil <nikhil....@intel.com>; > hemant.agra...@nxp.com; Ma, Liang J <liang.j...@intel.com> > Cc: dev@dpdk.org > Subject: Re: [PATCH 01/13] examples/eventdev: add Rx adapter support > > On Mon, Dec 11, 2017 at 04:15:41PM +0000, Eads, Gage wrote: > > Hi Pavan, > > > > </snip> > > > > > static inline void > > > schedule_devices(unsigned int lcore_id) { > > > if (fdata->rx_core[lcore_id] && (fdata->rx_single || > > > rte_atomic32_cmpset(&(fdata->rx_lock), 0, 1))) { > > > - producer(); > > > + rte_service_run_iter_on_app_lcore(fdata->rxadptr_service_id, > > > 1); > > > rte_atomic32_clear((rte_atomic32_t *)&(fdata->rx_lock)); > > > } > > > > The (rx_single || cmpset(rx_lock)) check should no longer be needed -- this > logic is provided in rte_service_run_iter_on_app_lcore() and service_run(). > The > rx_lock can be dropped in general. > > > > we could either remove the example level locks (or) keep the locks at > application > level and disable them in service api through > rte_service_run_iter_on_app_lcore(<id>, 0). > > If we choose to remove example level locks we could do something like > rte_service_run_iter_on_app_lcore(id, !rx_single) >
That sounds good. No need to duplicate code that the EAL provides, and it simplifies the example. Thanks, Gage
