From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 3815F4C80 for ; Wed, 13 Mar 2019 09:16:24 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 23EBB3884; Wed, 13 Mar 2019 04:16:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 13 Mar 2019 04:16:23 -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=0MwlgYXLOi6EALr9NPoPcxO760weaISgTt6PJTErAMQ=; b=I2K2+FNsdF/O cGp2d0cB6HynJsUZf9u7p+z2mUw+535STJVDJBhluQzVOQRcgfN68feePeZNCa5Z j/GKvk1l+QCjhAoBMgkW0+5Wmqc5DZMdq/J/ZqUzfA0t1qGJRUtwN+2lz4JP4EFH 6+QBpLKACH38zWbwJ2CU3WGIbkBXCO0= 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=0MwlgYXLOi6EALr9NPoPcxO760weaISgTt6PJTErA MQ=; b=cu0zjjpP00hI62ce50w95nxhzTlhC8SSLLpyG1UcZwN2yheFiMTg6dUZM 7FcT41yoSZCkbPTkDyJV5N1rKh0y9wsLUlu0CR90gUf68SZtBUwbKN6nyrRhJo0A FlJbtyEIWbQAu/i8EtWMw6Cr0fTqgHF8alWANWIHkUsBqE8XeMEXRU5f2tsPS4SZ HjUJQhTxb1ri126Quxa8q8nB8z9ftNN3+CmyyFxQ0/BQLx+hgDp6F3atYQQYxVEP xhR/0LF625FxCztj/CHe+JbbDN6blr9nP6GnHQNnCeKRvmuZZ+i7xi7veBdobR+m so0coiEDzB5gEA6My4LBd8PwgIRuA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgeelgdduudejucetufdoteggodetrfdotf 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 5F70110345; Wed, 13 Mar 2019 04:16:21 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Kollanukkaran Cc: "ferruh.yigit@intel.com" , "dev@dpdk.org" Date: Wed, 13 Mar 2019 09:16:20 +0100 Message-ID: <7977687.UUuBlTnzMO@xps> In-Reply-To: References: <20170807120408.21975-1-jerin.jacob@caviumnetworks.com> <2586565.KhPdhcutYW@xps> 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: Wed, 13 Mar 2019 08:16:24 -0000 13/03/2019 09:02, Jerin Jacob Kollanukkaran: > On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote: > > 12/03/2019 20:25, Jerin Jacob Kollanukkaran: > > > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote: > > > > 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> > > > > > > > > --- > > > > > > > > > > > > > > > > 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? > > # It should be like FreeBSD or Windows EAL port(Where changes should be > in lib/librte_eal/xxxxxx/) > # Baremetal libc can be newlibc or musl. > # IMO, If bare metal code is open source then the dependency does not > matter > # if RTOS supports POSIX wrappers, the common code changes will be very > minimal. > # In house, We have baremetal support as PoC, where 95% of changes are > in lib/librte_eal/xxxxxx/ with POSIX wrappers. Then maybe you should send your patches so we can decide if it is maintainable enough or not.