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 19:56:16 +0530 Message-ID: <20180730142614.GA11265@jerin> References: <20180730075408.GA14117@jerin> <80CC5C07-0D73-4F86-9F93-0AB78DEF2BFD@nokia.com> <20180730092921.GA22242@jerin> <20180730103638.GA26701@jerin> <75889C0D-2790-4EB8-B202-1311D764CCF2@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Van Haaren, Harry" , "dev@dpdk.org" To: "Elo, Matias (Nokia - FI/Espoo)" Return-path: Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680078.outbound.protection.outlook.com [40.107.68.78]) by dpdk.org (Postfix) with ESMTP id E9AFA58C4 for ; Mon, 30 Jul 2018 16:26:27 +0200 (CEST) Content-Disposition: inline In-Reply-To: <75889C0D-2790-4EB8-B202-1311D764CCF2@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 13:36:35 +0000 > From: "Elo, Matias (Nokia - FI/Espoo)" > To: Jerin Jacob > CC: "Van Haaren, Harry" , "dev@dpdk.org" > > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status > x-mailer: Apple Mail (2.3445.9.1) > > > >> For this "runtime scale down" use-case the missing information is being > >> able to identify when an unlink is complete. After that (and ensuring the > >> port buffer is empty) the application can be guaranteed that there are no > >> more events going to be sent to that port, and the application can take > >> the worker lcore out of its polling-loop and put it to sleep. > >> > >> As mentioned before, I think an "unlinks_in_progress()" function is perhaps > >> the easiest way to achieve this functionality, as it allows relatively simple > >> tracking of unlinks() using an atomic counter in sw. (Implementation details > >> become complex when we have a separate core running event/sw, separate cores > >> polling, and a control-plane thread calling unlink...) > >> > >> I think the end result we're hoping for is something like pseudo code below, > >> (keep in mind that the event/sw has a service-core thread running it, so no > >> application code there): > >> > >> int worker_poll = 1; > >> > >> worker() { > >> while(worker_poll) { > >> // eventdev_dequeue_burst() etc > >> } > >> go_to_sleep(1); > >> } > >> > >> control_plane_scale_down() { > >> unlink(evdev, worker, queue_id); > >> while(unlinks_in_progress(evdev) > 0) > >> usleep(100); > >> > >> /* here we know that the unlink is complete. > >> * so we can now stop the worker from polling */ > >> worker_poll = 0; > >> } > > > > > > Make sense. Instead of rte_event_is_unlink_in_progress(), How about > > adding a callback in rte_event_port_unlink() which will be called on > > unlink completion. It will reduce the need for ONE more API. > > > > Anyway it RC2 now, so we can not accept a new feature. So we will have > > time for deprecation notice. > > > > Both solutions should work but I would perhaps favor Harry's approach as it > requires less code in the application side and doesn't break backward > compatibility. OK. Does rte_event_port_unlink() returning -EBUSY will help? while (rte_event_port_unlink() != nr_links) usleep(100); I am trying to think, how can address this requirements without creating new API and/or less impact to other drivers which don't have this requirements? Are we calling this API in fastpath? or it is control thread as mentioned in harry's pseudo code.