[dpdk-dev] [PATCH 01/13] examples/eventdev: add Rx adapter support

Eads, Gage gage.eads at intel.com
Tue Dec 12 16:59:24 CET 2017



> -----Original Message-----
> From: Pavan Nikhilesh Bhagavatula
> [mailto:pbhagavatula at caviumnetworks.com]
> Sent: Tuesday, December 12, 2017 2:18 AM
> To: Eads, Gage <gage.eads at intel.com>;
> jerin.jacobkollanukkaran at cavium.com; Van Haaren, Harry
> <harry.van.haaren at intel.com>; Rao, Nikhil <nikhil.rao at intel.com>;
> hemant.agrawal at nxp.com; Ma, Liang J <liang.j.ma at intel.com>
> Cc: dev at 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


More information about the dev mailing list