From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 6DC102B9C for ; Wed, 28 Mar 2018 13:26:21 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B2A6B20DD0; Wed, 28 Mar 2018 07:26:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 28 Mar 2018 07:26:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=f42alBepGgbJigQtQaYbnJCGJE yNRs29cFkNUvkhnX8=; b=U5wRSy0vC0eti1s2o9uMSP/FruWNW6OkipULqb/ZGX +n75Kp6cjGzAxVxpmdlnET+JBV4QeNHmuMslwTLNbSaIcY18DpNx6cxJu0cyDui4 Z9t/eMOpE6oe2Y8k1Py7DzAv8AF3mmURjqPeaK4kIWHdYTFEdU322t4ycA6GVzza A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=f42alB epGgbJigQtQaYbnJCGJEyNRs29cFkNUvkhnX8=; b=l1o7pCmvxLwuROC4p/NxZT 0BoAExvjVehxcCXPqSEA+oWb+1tk+kvIqyccynWummtLHXr3DRQgf8/4ruEGPwYh OXHMmysiy6xzf0N3A8BuDwHKTDgmS8v57G4njOMJnWH/HnRpRSVGTb2E82EAR8qP 0u/8rJ8GegwqLJw7SwkDc0WTyni8BSC4fRj97lJHd4ELXqLVMbfgsmbIt+2yV5lO iGd25CIceKf089hP91LW0EXT1HCjBCeFyCz/eXVLfQvHJBlXLR2GbxGI+qhmbjQU NrrWCqwf4IDIRKwjBl7jQQHwTOycEePYjOKRoRysnq8nsPEt1IhH9Lhl//R5Qr2g == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C5673102A0; Wed, 28 Mar 2018 07:26:19 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: "Tan, Jianfeng" , "Van Haaren, Harry" , dev@dpdk.org, "Ananyev, Konstantin" , bruce.richardson@intel.com, olivier.matz@6wind.com Date: Wed, 28 Mar 2018 13:26:03 +0200 Message-ID: <2138949.TA61XZhXVp@xps> In-Reply-To: <5a7e8c12-9336-678a-ccdb-4938bb64e9c2@intel.com> References: <3288381.S1gyJAqTvN@xps> <5a7e8c12-9336-678a-ccdb-4938bb64e9c2@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 11:26:21 -0000 28/03/2018 12:42, Burakov, Anatoly: > On 28-Mar-18 10:53 AM, Thomas Monjalon wrote: > > 28/03/2018 11:21, Burakov, Anatoly: > >> so i don't think > >> it's such a big deal to have two IPC threads instead of one. I'm open to > >> suggestions on how to make this work without a second thread, but i > >> don't see it. > > > > I am not against the second thread. > > I am against both threads :) > > Well, the first thread is already in DPDK. To provide some context, > first implementation for DPDK IPC was suggested for 17.11, and (without > many conceptual changes) was merged in 18.02. I think it's a bit late to > be against both threads :) No, it's never too late to discuss. Merging a patch does not prevent discussing it :) > >> We've discussed possibility of using rte_service internally, but decided > >> against it for reasons already outlined by Harry - it's not a suitable > >> mechanism for this kind of thing, not as it is. > >> > >> Using interrupt thread for this _will_ work, however this will require a > >> a lot more changes, as currently alarm API allocates everything through > >> rte_malloc, while we want to use IPC for rte_malloc (which would make it > >> a circular dependency). So it'll probably be more API and more > >> complexity for dealing with malloc vs rte_malloc allocations. Hence the > >> least-bad approach taken here: a new thread. > > > > If everybody is happy enough with "least bad" design and not trying > > to improve the core design, what can I say? > > 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). 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. > 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.