[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