From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: eventdev: method for finding out unlink status
Date: Fri, 10 Aug 2018 23:05:11 +0530
Message-ID: <20180810173510.GA6835@jerin>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>,
 "dev@dpdk.org" <dev@dpdk.org>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam03on0075.outbound.protection.outlook.com [104.47.41.75])
 by dpdk.org (Postfix) with ESMTP id EEA9525D9
 for <dev@dpdk.org>; Fri, 10 Aug 2018 19:35:21 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA65E2B17A2@IRSMSX102.ger.corp.intel.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>

-----Original Message-----
> Date: Fri, 10 Aug 2018 16:55:31 +0000
> From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Elo, Matias (Nokia -
>  FI/Espoo)" <matias.elo@nokia.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>
> Subject: RE: [dpdk-dev] eventdev: method for finding out unlink status
> 
> 
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Friday, August 10, 2018 3:52 PM
> > To: Elo, Matias (Nokia - FI/Espoo) <matias.elo@nokia.com>
> > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
> >
> > -----Original Message-----
> > > Date: Fri, 10 Aug 2018 14:24:02 +0000
> > > From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
> > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > CC: "Van Haaren, Harry" <harry.van.haaren@intel.com>, "dev@dpdk.org"
> > >  <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?
> 
> 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 the documentation
about unlink() that it can be async call(currently it is documented as a sync
call).