From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: eventdev: method for finding out unlink status Date: Mon, 30 Jul 2018 14:59:23 +0530 Message-ID: <20180730092921.GA22242@jerin> References: <20180730075408.GA14117@jerin> <80CC5C07-0D73-4F86-9F93-0AB78DEF2BFD@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , "Van Haaren, Harry" To: "Elo, Matias (Nokia - FI/Espoo)" Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0079.outbound.protection.outlook.com [104.47.40.79]) by dpdk.org (Postfix) with ESMTP id F34E44C93 for ; Mon, 30 Jul 2018 11:29:35 +0200 (CEST) Content-Disposition: inline In-Reply-To: <80CC5C07-0D73-4F86-9F93-0AB78DEF2BFD@nokia.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" -----Original Message----- > Date: Mon, 30 Jul 2018 09:17:47 +0000 > From: "Elo, Matias (Nokia - FI/Espoo)" > To: Jerin Jacob > CC: "dev@dpdk.org" , "Van Haaren, Harry" > > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status > x-mailer: Apple Mail (2.3445.9.1) > > > >> > >> In bug report https://bugs.dpdk.org/show_bug.cgi?id=60 we have been discussing > >> issues related to events ending up in wrong ports after calling > >> rte_event_port_unlink(). In addition of finding few bugs we have identified a > >> need for a new API call (or documentation extension) for an application to be > > > > From HW perspective, documentation extension should be enough. adding > > "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 the unlinked > port asynchronously. Can't we do, dequeue() in loop to get all the events from port. If dequeue returns with zero event then ports are drained up. Right? > > > > >> able to find out when an unlink() call has finished and no new events are > >> scheduled anymore to the particular event port. This is required e.g. when doing > >> clean-up after an application thread stops processing events. > > > > 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. OK. Makes sense. Doing unlink() and link() in fastpath is not a problem. Changing core assignment to event port is problem without stop(). I guess, you application or general would be OK with that constraint. > > > 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 thread_id == port_id), > so this shouldn't be an issue. > >