From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: eventdev: method for finding out unlink status Date: Fri, 10 Aug 2018 20:22:12 +0530 Message-ID: <20180810145209.GA2475@jerin> References: <20180730103638.GA26701@jerin> <75889C0D-2790-4EB8-B202-1311D764CCF2@nokia.com> <20180730142614.GA11265@jerin> <6D43DE84-583D-42E5-B298-0E7BDA0C17FB@nokia.com> <20180731083107.GA23233@jerin> <4C54AAAE-A872-47E1-B815-AF68965F9F3E@nokia.com> <20180809141814.GA15603@jerin> <4C66F1B2-02F0-4F6E-A6CD-6A3F44CDAB42@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "Van Haaren, Harry" , "dev@dpdk.org" To: "Elo, Matias (Nokia - FI/Espoo)" Return-path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0076.outbound.protection.outlook.com [104.47.42.76]) by dpdk.org (Postfix) with ESMTP id 8AA7F25D9 for ; Fri, 10 Aug 2018 16:52:28 +0200 (CEST) Content-Disposition: inline In-Reply-To: <4C66F1B2-02F0-4F6E-A6CD-6A3F44CDAB42@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: Fri, 10 Aug 2018 14:24:02 +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) > > > > > > # Other than that, I am still not able to understand, why not > > application wait until rte_event_port_unlink() returns. > > Making rte_event_port_unlink() blocking would be troublesome if one doesn’t care > about unlink completion. E.g. doing dynamic load balancing. By making it as blocking(i.e the rte_event_port_unlink() returns when unlink() completed) forcing everyone to care about unlink completion. Right? > > > > > # What in real word use case, application can, do other than waiting > > to complete rte_event_port_unlink(). If we try to put some logic in like, > > > > while (rte_event_port_unlink_in_progress(dev, port) > 0){ > > do_something(); > > } > > > > The do_something() will not be called in some platform at all. > > > > # Any idea on what will be the real world use case, where rte_event_port_unlink() called in fastpath? > > In our application this could be used for example to pause scheduling of new events while > working on an “expensive” event to minimise delays. It is also needed when destroying > queues, though calling this fast path is debatable (our application enables creating / > destroying queues at runtime). If I understand it correctly, Your current issue is, SW driver is not waiting for to complete the unlink() operation so that in your application you are seeing some abnormalities. > > These are perhaps not the best examples but I would be very cautious to make a function > blocking if there is even a small probability that it could be called from the fast path. Let assume even if it is called in fastpath, what else, we can really do other that calling rte_pause() in loop. realistically? after issuing unlink() operation. >