From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Elo, Matias (Nokia - FI/Espoo)" Subject: Re: eventdev: method for finding out unlink status Date: Mon, 30 Jul 2018 09:17:47 +0000 Message-ID: <80CC5C07-0D73-4F86-9F93-0AB78DEF2BFD@nokia.com> References: <20180730075408.GA14117@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Van Haaren, Harry" To: Jerin Jacob Return-path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0116.outbound.protection.outlook.com [104.47.0.116]) by dpdk.org (Postfix) with ESMTP id 559B84C97 for ; Mon, 30 Jul 2018 11:17:48 +0200 (CEST) In-Reply-To: <20180730075408.GA14117@jerin> Content-Language: en-US Content-ID: <20EC44194BD7AD48BFB4E5B5EB784088@eurprd07.prod.outlook.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >>=20 >> In bug report https://bugs.dpdk.org/show_bug.cgi?id=3D60 we have been di= scussing >> issues related to events ending up in wrong ports after calling >> rte_event_port_unlink(). In addition of finding few bugs we have identif= ied a >> need for a new API call (or documentation extension) for an application = to be >=20 > From HW perspective, documentation extension should be enough. adding=20 > "there may be pre-scheduled events and the application is responsible to = process them" > on unlink(). Since dequeue() has which queue it is dequeue-ed from, the > application can allays make action based on that(i.e, Is the event > post/pre to unlink) At least in case of SW eventdev the problem is how the application can know= that it has processed all pre-scheduled events. E.g. dequeue may return nothing = but since the scheduler is running as a separate process events may still end up to t= he unlinked port asynchronously. >=20 >> able to find out when an unlink() call has finished and no new events ar= e >> scheduled anymore to the particular event port. This is required e.g. wh= en doing >> clean-up after an application thread stops processing events. >=20 > If thread stopping then it better to call dev_stop(). At least in HW > implementation, For an application doing dynamic load balancing stopping the whole eventdev= is not an option. > A given event port assigned to a new lcore other than > it previous one then we need to do some clean up at port level. In my case I'm mapping an event port per thread statically (basically thre= ad_id =3D=3D port_id), so this shouldn't be an issue.