From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A76E14C9F for ; Wed, 12 Sep 2018 17:17:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 08:17:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,365,1531810800"; d="scan'208";a="70312750" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga008.fm.intel.com with ESMTP; 12 Sep 2018 08:17:08 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.180]) by IRSMSX103.ger.corp.intel.com ([169.254.3.234]) with mapi id 14.03.0319.002; Wed, 12 Sep 2018 16:17:08 +0100 From: "Van Haaren, Harry" To: "Elo, Matias (Nokia - FI/Espoo)" CC: Jerin Jacob , "dev@dpdk.org" Thread-Topic: [dpdk-dev] eventdev: method for finding out unlink status Thread-Index: AQHUJ9Aasi5EGf77JEeq3+fzpPRPXKSnVJsAgAAXXYCAAAM+gIAAETgQgAABlYCAADJEgIAADeEAgAEo84CAAAYpAIAAD8iAgAydH4CAAdS58IAABFqAgAGT8ACAAAfeAIAAI9MAgAAJt4CAKDjmgIALgRXA Date: Wed, 12 Sep 2018 15:17:07 +0000 Message-ID: References: <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> <20180810145209.GA2475@jerin> <20180810173510.GA6835@jerin> <285D18AA-EC23-4C04-824A-726F20681C61@nokia.com> In-Reply-To: <285D18AA-EC23-4C04-824A-726F20681C61@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTZkZTAwMDAtOWRmOS00ZDBkLWI2YzItODBkNTA1ODVkYTliIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYlhRSUY2TmVmWGdvZUpWM1BMSG41OFZQdDFRQkNnbmU1QjJPMUg1T09OYUJobWtianNsRDlvaVk4SHJzT1NpYyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 15:17:11 -0000 > From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias.elo@nokia.com] > Sent: Wednesday, September 5, 2018 8:49 AM > To: Van Haaren, Harry > Cc: Jerin Jacob ; dev@dpdk.org > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status >=20 >=20 > >> > >> I'm not sure I understand the issue here. > >> Is anybody suggesting to make unlink() blocking? > >> > >> For certain PMDs, perhaps it must be a synchronous handled unlink(). > >> For other PMDs (eg event/sw) there are multiple threads involved, > >> so it must be async. Hence, APIs should be async to avoid blocking the > caller. > >> > >> With an async API, if you don't want the async behaviuor, it is > >> easy to build the sync version: call it in a loop, optionally with a > delay(). > > > > Correct. My point was, rte_event_port_unlink() can be blocking as it > > is a slow path API(does not really matter how long it waits). > > If you think, it can be called in fastpath and/or application can > > leverage some cpu cycles on completing the async call then you can add > > at the cost of new API unlinks_in_progress() and make sure to update th= e > documentation > > about unlink() that it can be async call(currently it is documented as = a > sync > > call). >=20 > Did you come to an agreement how to solve this issue? Any solution (e.g. > make > rte_event_port_unlink() blocking with SW eventdev) would be welcomed sinc= e > this > issue is currently blocking my work with eventdev. I'll work on a patch and document async behavior as Jerin suggested. I think we may still need to drain the port after unlinks_in_progress() ret= urns zero, as there may still be events in the port buffers until all unlinks ar= e done. That would make the final application code-path as follows: /* control path core */ unlink(); while(unlinks_in_progress() > 0) { delay(); } /* we know there are no more events being scheduled to the port. Could flag to data-path core here that unlinks are acked */ while(dequeue_burst(events, ... ) > 0) { free_events(); } /* now we know there are no events in the port itself either. Application can perform whatever it wants with the data-path core */ The final dequeueing could also be handled in the data-path core, and only break out of its loop when the unlink-ack and zero packets returne= d from dequeue. I'll send a v1 patchset for your reviews - I think that might make things c= learer. Thanks, -Harry