From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E3C44A034F; Wed, 31 Mar 2021 11:07:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C53C34069E; Wed, 31 Mar 2021 11:07:55 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id D137D40141 for ; Wed, 31 Mar 2021 11:07:54 +0200 (CEST) IronPort-SDR: sFozShaKODGKUCshSBys4Oe5QA8WRKBjg6I3yvykVXuYMt/eItU7dW1vq0TRDzxEDwv5NTgQ67 Qq5+tGFmrmqg== X-IronPort-AV: E=McAfee;i="6000,8403,9939"; a="188700155" X-IronPort-AV: E=Sophos;i="5.81,293,1610438400"; d="scan'208";a="188700155" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2021 02:07:53 -0700 IronPort-SDR: zHkz5Ky2OC7NtJJjOJPibzBGtfnEuvQlyQDktJV5x8jQQCgIQWY5vebdbr6OcFQjY6GL7vmIU+ /rcTOYOKEDAw== X-IronPort-AV: E=Sophos;i="5.81,293,1610438400"; d="scan'208";a="418576426" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.29.162]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 31 Mar 2021 02:07:50 -0700 Date: Wed, 31 Mar 2021 10:07:46 +0100 From: Bruce Richardson To: Juraj =?utf-8?Q?Linke=C5=A1?= Cc: Honnappa Nagarahalli , Jerin Jacob , Ruifeng Wang , "vcchunga@amazon.com" , Dharmik Thakkar , "hemant.agrawal@nxp.com" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , "ferruh.yigit@intel.com" , "aboyer@pensando.io" , "lironh@marvell.com" , "dev@dpdk.org" , nd Message-ID: <20210331090746.GA249@bricha3-MOBL.ger.corp.intel.com> References: <72c3c54c66754753a268b31a68afc38b@pantheon.tech> <9579a4ddba1343c681ba193a693b4bd1@pantheon.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9579a4ddba1343c681ba193a693b4bd1@pantheon.tech> Subject: Re: [dpdk-dev] [PATCH v16 1/3] build: disable/enable drivers in Arm builds X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On Wed, Mar 31, 2021 at 08:39:57AM +0000, Juraj Linkeš wrote: > > > > -----Original Message----- > > From: Honnappa Nagarahalli > > Sent: Tuesday, March 30, 2021 2:39 AM > > To: Jerin Jacob ; Juraj Linkeš > > > > Cc: Bruce Richardson ; Ruifeng Wang > > ; vcchunga@amazon.com; Dharmik Thakkar > > ; hemant.agrawal@nxp.com; Ajit Khaparde > > (ajit.khaparde@broadcom.com) ; > > ferruh.yigit@intel.com; aboyer@pensando.io; lironh@marvell.com; > > dev@dpdk.org; nd ; Honnappa Nagarahalli > > ; nd > > Subject: RE: [PATCH v16 1/3] build: disable/enable drivers in Arm builds > > > > > > > > > > > > > > > > > > > > > > > > > > The blocklist is, I think, agreed upon by everyone. > > > > > > > > > > > > The question is whether we want to support the > > > > > > > > > > > > allowlist alongside it and there seem to be enough > > > > > > > > > > > > reasons to do > > > that. > > > > > > > > > > > Sorry, may be this is answered already, but, what > > > > > > > > > > > additional benefit does allowlist provide over the blocklist? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > VPP could use it: > > > > > > > > > > https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=build/e > > > > > > > > > > xt > > > > > > > > > > erna > > > > > > > > > > l/pa > > > > > > > > > > ckag es/dpdk > > > > > > > > > > .mk;h=c35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=HEAD > > > > > > > > > > > > > > > > > > > > They're disabling almost everything so an allowlist would fit there. > > > > > > > > > > And they won't need to update the list when a new driver > > > > > > > > > > is added (which they won't need). > > > > > > > > > This is different from how we started this discussion. The > > > > > > > > > current discussion was for DPDK internal use. But the one > > > > > > > > > you are referencing above is for users of DPDK. I am fine > > > > > > > > > for providing the allow list for the users of DPDK. But > > > > > > > > > for DPDK internal, I think block list is > > > > > > > enough. > > > > > > > > > > > > > > > > > > > > > > > > > That's an interesting suggestion. Jerin, what do you think? > > > > > > > > Why did you > > > > > > > want to have an allowlist? Would this work? > > > > > > > > > > > > > > # The very reason why VPP chooses to have allow list so that > > > > > > > they can control what needs to include. > > > > > > > # Another use case is like, in SoCs have fixed internal > > > > > > > devices, we can have optimized build for that can have only > > > > > > > allow list of the drivers that care about # For server market, > > > > > > > block list makes sense # For embedded SoC, allow list makes sense. > > > > > > For the embedded SoC, IMO, the upstream project could allow the > > > > > > compilation > > > > > for wider set of PMDs/libs. May be the end customer can use the > > > > > allow list to compile/use what is required? > > > > > > > > > > Just to understand, how end customer can enable allow list, if > > > > > DPDK build system does not support it? > > > > > Also to understand, If we are supporting blocklist, why not have > > > > > allowlist (I mean, both of them) as both are required as it caters > > > > > different use case as mention above. We can not emulate allowlist > > > > > with blocklist as each version of DPDK will have new libraries and > > > > > PMD's > > > which end user has no clue. Right? > > > > > > > > > I think, that is the reason why VPP is doing the allow list. > > > > > > > > I'm not sure what you mean by this, but to clarify, VPP likely would > > > > be using > > > the allowlist in this fashion, but that is not an arm specific > > > usecase. I think what Honnappa wanted to see was how the allowlist > > > could be used in an arm usecase (such as using it in an SoC configuration). > > > > > > There is nothing arm-specific here. Right? allowlist will be common > > > and will be used by all architecture. Right? > > Nothing Arm specific. I think for generic Arm servers platforms we can make > > sure that we allow for compilation of all the DPDK code. We can go ahead with > > implementing the allow list. > > > > I tried to actually use an allowlist and there are some problems with building apps and tests. When I tried to enable a random driver, such as common/sfc_efx, I've ran into dependency issues with apps: > app/meson.build:53:3: ERROR: Tried to get unknown variable "static_rte_bus_vdev". > > This is because bus/vdev is not enabled (the allowlist only enabled net/sfc_efx). When I implemented dependency discovery in apps similar to which exists for drivers/libs, I was then unable to build tests (which is a special case app): > app/test/meson.build:427:1: ERROR: Tried to get unknown variable "static_rte_bus_pci". > > This is becasue bus/pci is not enabled. If I understand the code correctly, the test dependencies are not matched to each test, meaning we can't disable the tests for which we don't have dependencies - we can only disable all tests. > > In general, this problem also affects the blocklist, i.e. meson build -Ddisable_drivers=bus/pci produces > drivers/net/hinic/base/meson.build:34:0: ERROR: Unknown variable "static_rte_bus_pci". > For blocklists, this is seldom going to be a problem, since most users won't disable "core" drivers. > > I'm not sure what is the best course of action. We can implement the allowlist and then we'll leave it up to implementers to implement allowlists that produce a working build. We could then optionally address the dependency issues brought by disabled drivers in a separate patch. > > Maybe we can just have a list of "core" drivers that can never be disabled (either using blocklists or allowlists)? > > Bruce, what do you think? > Hi, from my experience this mainly seems to affect the bus drivers, specifically pci and vdev buses, which seem to be assumed to be always enabled. I agree it's probably not a real problem right now, though it would be nice for some testing purposes to have a build possible with "disable_drivers=*/*". For a solution I am happy for us to have whichever is easiest to implement - either refusing disabling of bus/pci and bus/vdev, or fixing the tests and apps to allow them to be built with reduced functionality. Apart from those two drivers, I would hope that disabling everything else works. If not, we should definitely fix it. /Bruce