From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eads, Gage" Subject: Re: [PATCH 01/13] examples/eventdev: add Rx adapter support Date: Tue, 12 Dec 2017 15:59:24 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E2BB16F44@FMSMSX108.amr.corp.intel.com> References: <20171207203705.25020-1-pbhagavatula@caviumnetworks.com> <20171207203705.25020-2-pbhagavatula@caviumnetworks.com> <9184057F7FC11744A2107296B6B8EB1E2BB1623A@FMSMSX108.amr.corp.intel.com> <20171212081757.aarmhwpaduvgjaic@Pavan-LT> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Pavan Nikhilesh Bhagavatula , "jerin.jacobkollanukkaran@cavium.com" , "Van Haaren, Harry" , "Rao, Nikhil" , "hemant.agrawal@nxp.com" , "Ma, Liang J" Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A37E72030 for ; Tue, 12 Dec 2017 16:59:26 +0100 (CET) In-Reply-To: <20171212081757.aarmhwpaduvgjaic@Pavan-LT> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Pavan Nikhilesh Bhagavatula > [mailto:pbhagavatula@caviumnetworks.com] > Sent: Tuesday, December 12, 2017 2:18 AM > To: Eads, Gage ; > jerin.jacobkollanukkaran@cavium.com; Van Haaren, Harry > ; Rao, Nikhil ; > hemant.agrawal@nxp.com; Ma, Liang J > Cc: dev@dpdk.org > Subject: Re: [PATCH 01/13] examples/eventdev: add Rx adapter support >=20 > On Mon, Dec 11, 2017 at 04:15:41PM +0000, Eads, Gage wrote: > > Hi Pavan, > > > > > > > > > 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. > > >=20 > we could either remove the example level locks (or) keep the locks at app= lication > level and disable them in service api through > rte_service_run_iter_on_app_lcore(, 0). >=20 > If we choose to remove example level locks we could do something like > rte_service_run_iter_on_app_lcore(id, !rx_single) >=20 That sounds good. No need to duplicate code that the EAL provides, and it s= implifies the example. Thanks, Gage