From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id EAFBF4C8F for ; Tue, 12 Mar 2019 21:33:59 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DBBC021964; Tue, 12 Mar 2019 16:33:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 12 Mar 2019 16:33:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=h9UDR1zhHwY0LB6P7QuEnKGQ0ohpVcJNARWYu0zkX5s=; b=ZW6ahvqLLndm iJSZKfpbwdGmcrd9ay8upy48DFEgxQ2aignrXCE3gLLwAxcMYhjpLRZ8Z9xP1fss 1NgsSeBl65z7Zhu/EHom3tHCKHbRNMOljHGOSVrihNaJgbKrD985Gdq/KslCn4em +2/7ESRJeYQrfNO0rhvoS3Yv3mBQRog= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=h9UDR1zhHwY0LB6P7QuEnKGQ0ohpVcJNARWYu0zkX 5s=; b=f7wkJEoq+6lxbN4uGdmuwUWUeAiohMYdNsXHXDeudEe4shZgJEsCqq/SG KP2QjfimvTMLVd5rIIks246otUwkBqac1xmR3TLf6M0J809v/2EvsxXNO9JwYYIF fyJKveeQwsYIUbE+B9jJM/lTf6rVaPJ01cFnRV7EKHYY3yJ5uxjCkTYIlEZwpa/N ndkS/Z1oKOMB2erwmwIXw7yvTq/i96hGsOLx7yZFpyyQQzuUFC/SlwH+mGY/45VW lnySddXeL2mKsfWCyotcFTbwnCraR+YfrKWaLVrrn5p1nSF+A3IJUHefM7BbuOED cMpVRyEMHIceZAMVRSzRQDNTGtfxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgeekgddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehmohhnjhgrlhhonhdrnhgvthdptggrvhhiuhhmnhgvthifohhrkhhsrdgt ohhmnecukfhppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigv pedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 54EA6E4697; Tue, 12 Mar 2019 16:33:57 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Kollanukkaran Cc: "ferruh.yigit@intel.com" , "dev@dpdk.org" Date: Tue, 12 Mar 2019 21:33:52 +0100 Message-ID: <2586565.KhPdhcutYW@xps> In-Reply-To: <60e55d6305c357c8d4bc46d56263b6f5485df84f.camel@marvell.com> References: <20170807120408.21975-1-jerin.jacob@caviumnetworks.com> <2668267.HQ7s86BJXi@xps> <60e55d6305c357c8d4bc46d56263b6f5485df84f.camel@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] eal: change init macro as exec environment specific 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: Tue, 12 Mar 2019 20:34:00 -0000 12/03/2019 20:25, Jerin Jacob Kollanukkaran: > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote: > > External Email > > > > ------------------------------------------------------------------- > > --- > > 01/03/2019 18:05, Ferruh Yigit: > > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin > > > Jacob) wrote: > > > > From: Thomas Monjalon > > > > > 07/08/2017 14:04, Jerin Jacob: > > > > > > baremetal execution environments may have a different > > > > > > method to enable RTE_INIT instead of using compiler > > > > > > constructor scheme. Move RTE_INIT* definition under > > > > > > exec-env to support different execution environments. > > > > > > > > > > > > Signed-off-by: Jerin Jacob > > > > > caviumnetworks.com> > > > > > > --- > > > > > > app/test-eventdev/evt_test.h | 2 +- > > > > > > lib/librte_eal/bsdapp/eal/Makefile | 2 +- > > > > > > .../bsdapp/eal/include/exec-env/rte_eal.h | 51 > > > > > > ++++++++++++++++++++++ > > > > > > lib/librte_eal/common/eal_common_log.c | 2 + > > > > > > lib/librte_eal/common/include/rte_bus.h | 2 + > > > > > > lib/librte_eal/common/include/rte_eal.h | 6 --- > > > > > > lib/librte_eal/common/include/rte_tailq.h | 2 + > > > > > > lib/librte_eal/linuxapp/eal/Makefile | 2 +- > > > > > > .../linuxapp/eal/include/exec-env/rte_eal.h | 51 > > > > > > ++++++++++++++++++++++ > > > > > > 9 files changed, 111 insertions(+), 9 deletions(-) > > > > > > create mode 100644 lib/librte_eal/bsdapp/eal/include/exec- > > > > > > env/rte_eal.h > > > > > > create mode 100644 lib/librte_eal/linuxapp/eal/include/exec- > > > > > > env/rte_eal.h > > > > > > > > > > I am not a big fan of duplicating code for Linux and BSD. > > > > > > > > > > Maybe we should have different splits and include a common file > > > > > in Linux and BSD? > > > > > > > > OK. This is doable. > > > > > > > > > I feel it would be easier to think about the split when adding > > > > > a new environment. > > > > > It is also an open question whether we want to support (again) > > > > > some > > > > > bare metal environments. > > > > > > > > IMO, A factor could be, how much we are OK to change? > > > > > > > > Our internal prototype implementation for a bare metal > > > > environment > > > > shows things are already in place and may need minor changes like > > > > this to > > > > accommodate a bare metal execution environment(accounting the > > > > latest > > > > changes of moving pci to driver/pci/..) > > > > > > > > If no one care about need for such abstraction then we could drop > > > > this > > > > patch. We can always keep local copy of such patches in our > > > > internal > > > > tree. I thought to upstream it as it may be useful for someone > > > > else and > > > > it is easy for us maintain if changes are in > > > > lib/librte_eal//eal/ and drivers/*/ > > > Hi Jerin, Thomas, > > > > > > This is an old patch, the abstraction seems good idea but it comes > > > with a > > > duplication. > > > > > > Is there an intention to continue the work? Are we waiting for any > > > decision? > > > Any objection to mark it as rejected? > > > > I am not sure there is a real desire to make DPDK > > ready for bare-metal (back again). > > If any of you are aware of a real use-case, we can re-consider. > > Some of the usecases: > > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe card), May > not need to waste one core for Linux. Specially Smart NIC market has > less number of cores. > On the endpoint side, It treats as FW so customer may not have access > to so nobdoy cares it is Linux or baremetal so may need to waste one > core for Linux > > # VM case, it possible to have bare metal guest just to save one a > logical core for Linux > > # Some of the RTOS like Zephyr already provide TCP/IP stack and good > subsystems for specific usecases. > > # We are using DPDK for pre silicon validation for SoC mode. Bringing > up linux on emulator takes ages, Baremetal can be used for Harware > verification too. > > > IMO, As long as it not limiting the a feature of Linux app, Why not to > allow baremetal? I agree with code duplication. I think, it can be > fixed easily, Other than that, Is there any concern? The concern is about the effort required. Which libc to use? Which dependency is acceptable?