From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pavan Nikhilesh Bhagavatula <pbhagavatula@caviumnetworks.com>
Subject: Re: [PATCH 01/13] examples/eventdev: add Rx adapter
	support
Date: Tue, 12 Dec 2017 13:47:58 +0530
Message-ID: <20171212081757.aarmhwpaduvgjaic@Pavan-LT>
References: <20171207203705.25020-1-pbhagavatula@caviumnetworks.com>
 <20171207203705.25020-2-pbhagavatula@caviumnetworks.com>
 <9184057F7FC11744A2107296B6B8EB1E2BB1623A@FMSMSX108.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org
To: "Eads, Gage" <gage.eads@intel.com>,
 "jerin.jacobkollanukkaran@cavium.com" <jerin.jacobkollanukkaran@cavium.com>,
 "Van Haaren, Harry" <harry.van.haaren@intel.com>, nikhil.rao@intel.com,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
 "Ma, Liang J" <liang.j.ma@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM02-CY1-obe.outbound.protection.outlook.com
 (mail-cys01nam02on0057.outbound.protection.outlook.com [104.47.37.57])
 by dpdk.org (Postfix) with ESMTP id 60173293B
 for <dev@dpdk.org>; Tue, 12 Dec 2017 09:18:14 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E2BB1623A@FMSMSX108.amr.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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