From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH v6 2/2] eal: add asynchronous request API to DPDK IPC Date: Wed, 28 Mar 2018 13:21:30 +0100 Message-ID: <92df6ce3-6657-76ac-c07b-8a0798f06106@intel.com> References: <3288381.S1gyJAqTvN@xps> <5a7e8c12-9336-678a-ccdb-4938bb64e9c2@intel.com> <2138949.TA61XZhXVp@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Tan, Jianfeng" , "Van Haaren, Harry" , dev@dpdk.org, "Ananyev, Konstantin" , bruce.richardson@intel.com, olivier.matz@6wind.com To: Thomas Monjalon Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id D9F7710B7 for ; Wed, 28 Mar 2018 14:21:34 +0200 (CEST) In-Reply-To: <2138949.TA61XZhXVp@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 28-Mar-18 12:26 PM, Thomas Monjalon wrote: > 28/03/2018 12:42, Burakov, Anatoly: >> On 28-Mar-18 10:53 AM, Thomas Monjalon wrote: >>> 28/03/2018 11:21, Burakov, Anatoly: >> I'm not against trying to improve the core design. I'm just saying that, >> had this kind of feedback been provided just a bit earlier, I would've >> had time to fix it in time for deadlines. However, because memory rework >> patchset depends on this API, i would suggest merging it in now, as is, >> and commit to a roadmap of improvements for next release(s). > > Actually, you had the feedback yourself from the beginning. > You decided to gave up with interrupt thread because its implementation > is not complete (and maybe far from perfect). That's not quite how i see it, but OK, suppose so. > There are some communities where it is not acceptable to workaround > core issues because of timing issues. I think we accept it in DPDK, > but I continue to question it, in order to be sure that everybody is OK > with this kind of tradeoff. The way i see it, not all API's are equal; some are more important than others. This is a new, experimental API that is not core to any DPDK function - it's not used on any hotpaths nor is it even that demanding (the two threads will be sleeping 99.999% of the time anyway). I think we're allowed to experiment on it before settling on an implementation that satisfies everyone :) >> For starters, we could plan on removing alarm thread's dependency on >> rte_malloc and just use regular malloc API's in there, and rework >> asynchronous IPC API to use that instead. This shouldn't be much work, >> and will presumably make you halfway happy, as one of the threads will >> be gone :) >> >> We can then look into removing the second thread and moving the entirety >> of DPDK IPC into the interrupt thread. I'm not too sure how would that >> work, but i haven't looked at it in any detail, so maybe it is feasible. >> >> Can we agree on this? It would be great to do everything perfectly from >> the first try, but having a goal in sight and working towards it is fine >> too, even if not all of the steps we take are perfect. > > The main concern is API. > If all these changes are internal only, and does not involve any major > API change, then I guess it is OK to pospone them in next release. > Yes, all of this is/will be internal to DPDK IPC - no externally visible changes whatsoever. -- Thanks, Anatoly