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 13:24:10 +0530 Message-ID: <20180730075408.GA14117@jerin> References: 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 NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0058.outbound.protection.outlook.com [104.47.32.58]) by dpdk.org (Postfix) with ESMTP id 73816374E for ; Mon, 30 Jul 2018 09:54:21 +0200 (CEST) Content-Disposition: inline In-Reply-To: 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 06:39:45 +0000 > From: "Elo, Matias (Nokia - FI/Espoo)" > To: "dev@dpdk.org" > CC: "Van Haaren, Harry" > Subject: [dpdk-dev] eventdev: method for finding out unlink status > x-mailer: Apple Mail (2.3445.9.1) > > > Hi, > > 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) > 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, 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. > > The bug report discussion provides more background on the subject and Harry has > already proposed a new 'int32_t rte_event_unlinks_in_progress()' API as one > possible solution. Assuming stale event(s) can go the new linked port, Does rte_event_unlink() takes consider amount of time in SW implementation. > > -Matias >