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)
> </snip>
>
> > + if (port_needed)
> > + prod_data.port_id = cons_data.port_id + 1;
> > + prod_data.dev_id = evdev_id;
> > + prod_data.qid = cdata.qid[0];
> > +
>
> Is prod_data still needed? Looks like we're only using it in main() to print
> the port ID (which may not be valid, depending on if port_needed is true).
Prod data is not needed I left it there to be consistent with the old example,
I will clean it up in the next version.
>
> Thanks,
> Gage
Thanks,
Pavan
