From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2018 05:21:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,371,1517904000"; d="scan'208";a="38818586" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.112]) ([10.237.220.112]) by orsmga003.jf.intel.com with ESMTP; 28 Mar 2018 05:21:31 -0700 To: Thomas Monjalon Cc: "Tan, Jianfeng" , "Van Haaren, Harry" , dev@dpdk.org, "Ananyev, Konstantin" , bruce.richardson@intel.com, olivier.matz@6wind.com References: <3288381.S1gyJAqTvN@xps> <5a7e8c12-9336-678a-ccdb-4938bb64e9c2@intel.com> <2138949.TA61XZhXVp@xps> From: "Burakov, Anatoly" Message-ID: <92df6ce3-6657-76ac-c07b-8a0798f06106@intel.com> Date: Wed, 28 Mar 2018 13:21:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2138949.TA61XZhXVp@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 2/2] eal: add asynchronous request API to DPDK IPC X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 12:21:35 -0000 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