From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
Subject: Re: eventdev: method for finding out unlink status
Date: Wed, 5 Sep 2018 07:49:13 +0000
Message-ID: <285D18AA-EC23-4C04-824A-726F20681C61@nokia.com>
References: <20180730142614.GA11265@jerin>
 <6D43DE84-583D-42E5-B298-0E7BDA0C17FB@nokia.com>
 <20180731083107.GA23233@jerin>
 <4C54AAAE-A872-47E1-B815-AF68965F9F3E@nokia.com>
 <FB101081-5D5A-4FEA-9352-048D47BA05A7@nokia.com>
 <E923DB57A917B54B9182A2E928D00FA65E2ADCA2@IRSMSX102.ger.corp.intel.com>
 <20180809141814.GA15603@jerin>
 <4C66F1B2-02F0-4F6E-A6CD-6A3F44CDAB42@nokia.com>
 <20180810145209.GA2475@jerin>
 <E923DB57A917B54B9182A2E928D00FA65E2B17A2@IRSMSX102.ger.corp.intel.com>
 <20180810173510.GA6835@jerin>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org" <dev@dpdk.org>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
 (mail-eopbgr00137.outbound.protection.outlook.com [40.107.0.137])
 by dpdk.org (Postfix) with ESMTP id A87E8F11
 for <dev@dpdk.org>; Wed,  5 Sep 2018 09:49:15 +0200 (CEST)
In-Reply-To: <20180810173510.GA6835@jerin>
Content-Language: en-US
Content-ID: <83921600B182E04DB24C1E40F9054D2E@eurprd07.prod.outlook.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


>>=20
>> I'm not sure I understand the issue here.
>> Is anybody suggesting to make unlink() blocking?
>>=20
>> 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 c=
aller.
>>=20
>> 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 del=
ay().
>=20
> Correct. My point was, rte_event_port_unlink() can be blocking as it=20
> 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 the =
documentation
> about unlink() that it can be async call(currently it is documented as a =
sync
> call).

Did you come to an agreement how to solve this issue? Any solution (e.g. ma=
ke
rte_event_port_unlink() blocking with SW eventdev) would be welcomed since =
this
issue is currently blocking my work with eventdev.