From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 71D38A04AA; Tue, 8 Sep 2020 11:46:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2147D1BEE1; Tue, 8 Sep 2020 11:46:38 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 991681BEAC for ; Tue, 8 Sep 2020 11:46:36 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 15FC3D4A; Tue, 8 Sep 2020 05:46:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 08 Sep 2020 05:46:35 -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=fm2; bh= /UjS0ENABSuwE82524zL9U86NDmQtwVa4SWIboUGj/E=; b=WiAW2S5l/KjdME/8 qGrQV31ZPTkqdC+1DrqX1xi5H2j69hHgwYLynaHGrr1c8B/bYVYDP25jpgD15BOf TF/Tx4qPYycJ/WHrSTRVZGLE1dYTMGmVQnGpPywf07hiZ7CggfzINZiC/9iQCgqm gI4smrC/psvE5DxCCT/xVDNlKjHAQieCpTZ4qYO+VG3XWe8qcOmnxyiePSZP8gar +05MUjdooOHLTUC1un7TpHfGAj6+xjhy3zu1O7eQY1Ym24hOY5o6n7KRjOGXd+Vh C+QxDndbDpxjDezyjSxbroiqkCOO88vwG8WcrR/MnNev7OJAaVsru8qu8IBxxpQj P0loog== 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=fm3; bh=/UjS0ENABSuwE82524zL9U86NDmQtwVa4SWIboUGj /E=; b=jNOXIE1X21gcmhSzheakIN2hDwkWo1iwijc2LzQWlvBLLV3kHr1c+fJuL Lm1pEjc42jQNz1Jm/9GgRpwp6auU2zzUc2mqHe2/1+Nqja/HtyxBxa5E37nLyO9c 709+aPFH1+PWGr33xZ/lC/KiVr5aKsjWp5UBxEtFr64SLxRd/DH0qatz1i8aTKJN psLYQVz4rA5L1FvdjongiAKdIpKpJXm2OM79n+cYJOoOS26DiUhTlZRjUTZzUOWU Qcmd1rQxlQI6hBTA1BqwU/ZXLlsQ79OTexEPk4Otrl6oVwnfdZHS1Kh4Nfkn7Nqw WyuVNWUEuH3Cb9aN/T2M1lIehOATg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehfedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 28AE93064682; Tue, 8 Sep 2020 05:46:33 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, david.marchand@redhat.com, ferruh.yigit@intel.com, jerinj@marvell.com, stephen@networkplumber.org Date: Tue, 08 Sep 2020 11:46:30 +0200 Message-ID: <9721798.A9spbk1rih@thomas> In-Reply-To: <20200908093430.GD351@bricha3-MOBL.ger.corp.intel.com> References: <20200907225049.547832-1-thomas@monjalon.net> <2557168.Xcie88ISVP@thomas> <20200908093430.GD351@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] kernel: remove igb_uio 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 08/09/2020 11:34, Bruce Richardson: > On Tue, Sep 08, 2020 at 11:27:23AM +0200, Thomas Monjalon wrote: > > 08/09/2020 10:25, Bruce Richardson: > > > On Tue, Sep 08, 2020 at 02:14:02AM +0200, Thomas Monjalon wrote: > > > > On Tue Sep 8, 2020 at 2:50 AM CEST, Thomas Monjalon wrote: > > > > > As decided in the Technical Board in November 2019, > > > > > the kernel module igb_uio is moved to the dpdk-kmods repository > > > > > in the /linux/igb_uio/ directory. > > > > > > > > The code is moved with its git history in > > > > http://git.dpdk.org/dpdk-kmods/ > > > > > > > > The move process started with these commands: > > > > cd dpdk > > > > dir=igb_uio > > > > path1=lib/librte_eal/linuxapp/$dir > > > > path2=kernel/linux/$dir > > > > git format-patch -o $dir 0c9a540ed2.. -- $path1 $path2 > > > > find $dir -type f -exec sed -i "s,$path1\|$path2,linux/$dir," '{}' \; > > > > cd ../dpdk-kmods > > > > git am ../dpdk/$dir/* > > > > git filter-branch --force > > > > --index-filter "git rm --cached --ignore-unmatch linux/$dir/Makefile" > > > > --prune-empty --tag-name-filter cat -- --all > > > > > > > > Makefile and meson.build files were not imported at all. > > > > Some other commits were skipped (virtio, vmxnet3 and Xen dom0 support), > > > > because they were not very useful and reverted later in the history. > > > > Anyway the original history is available forever in dpdk.git. > > > > > > > > Currently it cannot compile because the file rte_pci_dev_feature_defs.h > > > > is missing, defining enum rte_intr_mode. An option is to import this file. > > > > > > > > It would be nice to add a README file in the new igb_uio directory. > > > > Volunteers welcome :) > > > > > > In terms of building the module, one option which I think is worth > > > considering is to try and use meson subject/wrap support to download and > > > build this module as part of the main DPDK build, as now, when enable_kmods > > > option is set. With a wrap file in DPDK it can automatically pull down and > > > build the code as part of a main project build. I assume that integration > > > into main DPDK build is still something worth having? The only thing I > > > don't like about using a wrap file is that it has to be placed in a folder > > > called "subproject" at the top level of the DPDK project. > > > > The idea is encouraging the use of VFIO and make igb_uio deprecated. > > I think we should not do any effort to ease igb_uio usage inside dpdk.git. > > Compiling the kernel module standalone in dpdk-kmods.git looks enough, isn't it? > > Ok, that is fine if that is the objective. I thought the objective was to > move all kernel modules out of the DPDK tree, but if it's only certain > modules, then that is different. As we discussed in the Technical Board, the FreeBSD modules are required for any use and should stay inside dpdk.git. But the question is open for KNI. I think KNI should be deprecated as well to encourage using other methods which are more "upstream" for Linux.