From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Subject: Re: [PATCH v6 2/2] eal: add asynchronous request API to
 DPDK IPC
Date: Wed, 28 Mar 2018 02:08:56 +0000
Message-ID: <ED26CBA2FAD1BF48A8719AEF02201E36514A9BC0@SHSMSX103.ccr.corp.intel.com>
References: <cde1ac06bc0f7e6193df6582d8b8a3b62fe51d09.1522159146.git.anatoly.burakov@intel.com>
 <5d94df0912159b96aa71da5249598bd8c744a198.1522159146.git.anatoly.burakov@intel.com>
 <3396888.LEadjR7LpM@xps>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, "Van Haaren, Harry"
 <harry.van.haaren@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>, "Burakov, Anatoly"
 <anatoly.burakov@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id A7FFC1B021
 for <dev@dpdk.org>; Wed, 28 Mar 2018 04:09:32 +0200 (CEST)
In-Reply-To: <3396888.LEadjR7LpM@xps>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Thomas ,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, March 28, 2018 12:34 AM
> To: Burakov, Anatoly
> Cc: dev@dpdk.org; Tan, Jianfeng; Ananyev, Konstantin; Van Haaren, Harry
> Subject: Re: [dpdk-dev] [PATCH v6 2/2] eal: add asynchronous request API =
to
> DPDK IPC
>=20
> 27/03/2018 15:59, Anatoly Burakov:
> > Under the hood, we create a separate thread to deal with replies to
> > asynchronous requests, that will just wait to be notified by the
> > main thread, or woken up on a timer.
>=20
> I really don't like that a library is creating a thread.
> We don't even know where the thread is created (which core).
> Can it be a rte_service? or in the interrupt thread?

Agree that we'd better not adding so many threads in a library.

I was considering to merge all the threads into the interrupt thread, howev=
er, we don't have an interrupt thread in freebsd. Further, we don't impleme=
nt alarm API in freebsd. That's why I tend to current implementation, and o=
ptimize it later.

For rte_service, it may be not a good idea to reply on it as it needs expli=
cit API calls to setup.

>=20
>=20
> > --- a/lib/librte_eal/rte_eal_version.map
> > +++ b/lib/librte_eal/rte_eal_version.map
> > @@ -225,6 +225,7 @@ EXPERIMENTAL {
> >  	rte_mp_action_unregister;
> >  	rte_mp_sendmsg;
> >  	rte_mp_request;
> > +	rte_mp_request_async;
>=20
> So there is rte_mp_request and rte_mp_request_async?
> You should rename rte_mp_request, I guess.

+1.

Thanks,
Jianfeng

>=20
> >  	rte_mp_reply;
> >  	rte_service_attr_get;
> >  	rte_service_attr_reset_all;
>=20
>=20
>=20
>=20