From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 2A3D5FEB for ; Thu, 9 Aug 2018 15:14:50 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2018 06:14:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,215,1531810800"; d="scan'208";a="75161403" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga002.fm.intel.com with ESMTP; 09 Aug 2018 06:14:41 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.180]) by IRSMSX153.ger.corp.intel.com ([169.254.9.126]) with mapi id 14.03.0319.002; Thu, 9 Aug 2018 14:14:41 +0100 From: "Van Haaren, Harry" To: "Elo, Matias (Nokia - FI/Espoo)" CC: "dev@dpdk.org" , Jerin Jacob Thread-Topic: [dpdk-dev] eventdev: method for finding out unlink status Thread-Index: AQHUJ9Aasi5EGf77JEeq3+fzpPRPXKSnVJsAgAAXXYCAAAM+gIAAETgQgAABlYCAADJEgIAADeEAgAEo84CAAAYpAIAAD8iAgAydH4CAAdS58A== Date: Thu, 9 Aug 2018 13:14:40 +0000 Message-ID: References: <20180730075408.GA14117@jerin> <80CC5C07-0D73-4F86-9F93-0AB78DEF2BFD@nokia.com> <20180730092921.GA22242@jerin> <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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzQ4NDhkMmUtMDJiYS00Y2E4LWI2YWItZWE4NWVhZTMyYTUyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicGdOSlFDSURmbjFpTlF3cGx5NUYrRjA2V0xleW12aXphUkxOV0dTSzRrckdTT0FXWmVUcDI2OHBXb2xCWDdRTyJ9 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: Thu, 09 Aug 2018 13:14:51 -0000 > From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias.elo@nokia.com] > Sent: Wednesday, August 8, 2018 11:05 AM > To: Van Haaren, Harry > Cc: dev@dpdk.org; Jerin Jacob > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status >=20 >=20 > >>>>>>> > >>>>>>> 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 =3D 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 =3D 0; > >>>>>>> } > >>>>>> > >>>>>> > >>>>>> Make sense. Instead of rte_event_is_unlink_in_progress(), How abou= t > >>>>>> 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 approa= ch > as it > >>>>> requires less code in the application side and doesn't break backwa= rd > >>>>> compatibility. > >>>> > >>>> OK. > >>>> > >>>> Does rte_event_port_unlink() returning -EBUSY will help? > >>> > >>> It could perhaps work. The return value becomes a bit ambiguous thoug= h. > E.g. how > >>> to differentiate a delayed unlink completion from a scenario where th= e > port & queues > >>> have never been linked? > >> > >> Based on return code? > > > > Yes, that works. I was thinking about the complexity of the implementat= ion > as it would > > have to also track the pending unlink requests. But anyway, Harry is > better answering > > these questions since I guess he would be implementing this. >=20 >=20 > Hi Harry, >=20 > Have you had time to think about this? Hey, Yes I'm just collecting my thoughts at the moment, I see a few small q= uirks; 1) I see the "return -EBUSY from port_unlink()" solution as overloading the= rte_event_port_unlink() API. We lose some self-documenting semantics of the code, see the following snip= pet @ 1) marker. 2) If some unlinks fail, and others are in progress, we cannot describe tha= t in a single return. See 2) marker in code below. int ret =3D rte_event_port_unlink(dev, port, queues[], nb_queues); while (ret =3D=3D -EBUSY) { // 1) what args to pass here? It looks like we want to unlink again?=20 // 2) some unlinks fail, and others are -EBUSY: There is no appropriate = ret code in that case ret =3D rte_event_port_unlink(...); } Contrast that to the following, which I feel is simpler and more descriptiv= e: int ret =3D rte_event_port_unlink(dev, port, queues[], nb_queues); while (rte_event_port_unlink_in_progress(dev, port) > 0) rte_delay(); Here the port_unlink() call can sanity-check the unlinks, and return -EINVA= L if invalid requests, and we can detect other unlinks in progress too using the explicit API. Regarding adding an API / function-pointer, is there actually a measurable = cost there? Are we willing to sacrifice code-readability and self-documentation? -Harry