From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [PATCH v6 2/2] eal: add asynchronous request API to
 DPDK IPC
Date: Wed, 28 Mar 2018 10:11:58 +0100
Message-ID: <20180328091158.GA5544@bricha3-MOBL.ger.corp.intel.com>
References: <cde1ac06bc0f7e6193df6582d8b8a3b62fe51d09.1522159146.git.anatoly.burakov@intel.com>
 <3396888.LEadjR7LpM@xps>
 <ED26CBA2FAD1BF48A8719AEF02201E36514A9BC0@SHSMSX103.ccr.corp.intel.com>
 <2563064.olffpIeeN1@xps>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Tan, Jianfeng" <jianfeng.tan@intel.com>,
 "Burakov, Anatoly" <anatoly.burakov@intel.com>,
 "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>
Return-path: <dev-bounces@dpdk.org>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 710914C8C
 for <dev@dpdk.org>; Wed, 28 Mar 2018 11:12:27 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <2563064.olffpIeeN1@xps>
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>

On Wed, Mar 28, 2018 at 09:29:35AM +0200, Thomas Monjalon wrote:
> 28/03/2018 04:08, Tan, Jianfeng:
> > Hi Thomas ,
> > 
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 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.
> > > 
> > > 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, however, we don't have an interrupt thread in freebsd. Further, we don't implement alarm API in freebsd. That's why I tend to current implementation, and optimize it later.
> 
> I would prefer we improve the current code now instead of polluting more
> with more uncontrolled threads.
> 
+1
I think it would be worthwhile adding an interrupt thread to BSD, and it
should not be a massive amount of work. Having a single interrupt thread
has a lot of benefits, I think.

/Bruce