From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <harry.van.haaren@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id A76E14C9F
for <dev@dpdk.org>; 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" <harry.van.haaren@intel.com>
To: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
CC: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org" <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: <E923DB57A917B54B9182A2E928D00FA65E2C7D28@IRSMSX102.ger.corp.intel.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>
<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 <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>
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 <harry.van.haaren@intel.com>
> Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>; 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