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 903E5432BA; Mon, 6 Nov 2023 12:27:40 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2997A402AE; Mon, 6 Nov 2023 12:27:40 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 8A354402AA for ; Mon, 6 Nov 2023 12:27:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699270059; x=1730806059; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=CncXDz6/77B/udP2vlxd1aj2+asUR/NnuV8es7J9IDg=; b=jmdygNQstjIRiBshvHHkch9aAzNPw15Fe8vdMJM+GmXTDbQsxkA1v+o2 QiixFL4SurdhZSKFcSfP8L2fAemdcB0C/0vsvj7Wl4iM2ePcfAvfpDh2I ckufA15wrTTSwZBWO83rMchTcp6g5VuJluW9D4fQIbbvq2GCS0i/Ck9R3 wFNoORwTlcrm7P65fTUj7pdDrRFrmYybVFw4wewtrferPNiSCQrvb2A8L tiDV3/ZM5725qqZQ67AbLDNya4GocvJBbGtFwSNI6dyxwnAOpHc3CvZJo 1DMawIKTYc9XwJvvaiqsel6b1F/4a+wWiQBeFhFg6Y7Cw1wYVWk3v3BO+ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="379647805" X-IronPort-AV: E=Sophos;i="6.03,281,1694761200"; d="scan'208";a="379647805" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2023 03:27:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="879414574" X-IronPort-AV: E=Sophos;i="6.03,281,1694761200"; d="scan'208";a="879414574" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmsmga002.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 06 Nov 2023 03:27:36 -0800 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Mon, 6 Nov 2023 03:27:34 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Mon, 6 Nov 2023 03:27:33 -0800 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34 via Frontend Transport; Mon, 6 Nov 2023 03:27:33 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Mon, 6 Nov 2023 03:27:33 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fnegfhq6uxqc0tB1rd5E3qRiRAn7gaUHNYB4E7UW6NgdFcejiYpEVPNkYv2wWlOja5JqobNaJjenrz+Mmb2vHwbLA+xFch1KxnFrf8uwUOwegXKnJGv3PiHgd8r/ak2tQo/rDRvT91byMvQQHYNzSHHW7BGNWwPpvI5l4DCTmKO2Vf5YsCzfJWfQ7CYjF4omTWnnRHpiB9F+zCZ36SrAXY16ehaOMaTUYFmZFGilhXv/RngZrAto3UFRJY7ugI2UtCJ0+oJvF9PzdlUjiBvYPMQ27opnUWTjLB5YNrWiV+OSRvS4MsorsLR0CZ5W4gnep9EcdzOPccYQcu2KZD5ERA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=46Lrv45zh8/qA+wot0s3VhYthJrXswgs89Lct5bpWeI=; b=hJi+4xCgXMUY1heZId9RojZFJzAFXh1PS5sTCyUbtt5HAVZKUeejS6bsAxp011bRhEQBVnPi20PnpxTx82X6hQMTWIThszQe7AuR3ruTeceAtno8efGBTwQrXhezLiQaXvw7If1WvY/e9/8wtnFFNt+2yp5OVqm1lftKrXZdc93vau/cP5p+FnRv1fySNiwlGV7vCvG+qP2UdDUUWn2oZg3DztPTS4EaU2k2p3VCb12OQZ8yK+7U/5uS1aheLYr3Wn9dLxlwulVWGqtHL5GL9lbEc+hGRZNukgR5kVh4Ri4H+5p9kv4egxAvU14MXjEiPnqxzol9taF7OnznKJTmgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by MN6PR11MB8171.namprd11.prod.outlook.com (2603:10b6:208:471::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.28; Mon, 6 Nov 2023 11:27:31 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::8645:d921:ce8a:12ba]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::8645:d921:ce8a:12ba%5]) with mapi id 15.20.6954.028; Mon, 6 Nov 2023 11:27:30 +0000 Date: Mon, 6 Nov 2023 11:27:26 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Subject: Re: [PATCH 24.03 v2] build: track mandatory rather than optional libs Message-ID: References: <20231103162830.593702-1-bruce.richardson@intel.com> <20231103165208.1210182-1-bruce.richardson@intel.com> <98CBD80474FA8B44BF855DF32C47DC35E9EFCF@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9EFD0@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9EFD7@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFD7@smartserver.smartshare.dk> X-ClientProxiedBy: DB8PR04CA0022.eurprd04.prod.outlook.com (2603:10a6:10:110::32) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|MN6PR11MB8171:EE_ X-MS-Office365-Filtering-Correlation-Id: 6ca41b3c-d2fe-4254-2aa8-08dbdebb5d18 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FuIo+r72gZl8DSabBwiwHMzP+IJisicPNMZwwHlbxUMckqMxDHnrMIHGQJN0bFunDYx3J/UMhNSba7uvaZwnRm5Ffo0A+Gv+esIC4qjpj5/CS99CsRc3gX90+Uu+tmSPU+x7B9FhjvJeMujKdIRLiLAtw4HHk36EJUpXw/pkY0+7nvIeFiMOVP5jXaSlVitraC9Lgk1nj/gG0E+O44Q7PIpLgKfwNwpjO/0l1aUQgvcHDfT+ruJ15Nyckhw7wt1WS8/Ln0Lgjgqv2u4SH8J3We8g8z0RyOWv5B8WBGA/yZJLxNOE7cb9RsekWyHKwsv8S3lCt0YQSV7Kfe3tClxqPFyjOO720aMxsjYiusyB7Qhlz1ZUS4UeS1S9S7icThzTvl+RQ4Fi/Lp43kOM3Pp/5YBrg07VeG1bKVkLOGTUhx0DKKZm9sU+h332eESbVi0YmY75Me2MnAXZeXsL6h3Urjb3nSUjfwbwwcI/Kc4dWiWO/jfJ1B4y2GcguiUBfDjEs9IC37+7hFIxvJDOi6bTkeAAjArONlFLLuZRAJ70j2PoGES66IBXEYs2dO8ow9U0 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(136003)(366004)(396003)(39860400002)(346002)(230922051799003)(64100799003)(1800799009)(451199024)(186009)(83380400001)(4326008)(8936002)(41300700001)(44832011)(86362001)(8676002)(2906002)(6666004)(478600001)(6486002)(6506007)(38100700002)(6916009)(316002)(82960400001)(5660300002)(66556008)(66476007)(66574015)(26005)(66946007)(6512007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?ZKUKaEaE/ItADRV7xvr8XgC1aXxjx8cdz7V95F36rt2r94R9Ey14x21xLd?= =?iso-8859-1?Q?7dGuZlHt29MkMIh11gINtrwxhvVqk27JcRPhhUCIoQpLe3qDxnbscD4K3s?= =?iso-8859-1?Q?t0uZ0cXD4NTiWOzuumiMmrGWqVuLXYe+7y/XUZ6qeJdXeNXhZX9W+sTCuu?= =?iso-8859-1?Q?fs9YgOXZNHIQQS2KOt8vb0PNGod8ZbR5U5QgcyYOkHHMESFKMB9Onv2qDQ?= =?iso-8859-1?Q?9xV+YO4OzvKbMbcvDIc+u9/UP75GejDSC4dDThEFApFXw/X12NC5XroPj/?= =?iso-8859-1?Q?2B+/M3L5qOREdD4EHIVxLnb6yjP0sS6E92sHZ3lFY877ycSIK+1cwokB1g?= =?iso-8859-1?Q?hv/rZmfayl4FeYHc+eoYkhw5YanVeGZynLg098C9V+KUa9IiOMJsbZvzbb?= =?iso-8859-1?Q?k6klGPfFpcnkEJvHMcafuH6TmKCTQCCGMusY0RUIDD23tt6EHXWz33hsTH?= =?iso-8859-1?Q?BkrzIBS+ZU2ZW5hzDl9qipagmfPY4ZoosFIyxqGPDNGtokEVc8dKDH6Nnr?= =?iso-8859-1?Q?Tl8vLM342oXrnSazfl/s3KxIaKdR52wCsucg2jkKsaM70pDGIkWp+QX2Lw?= =?iso-8859-1?Q?O2YN2FjOqbO323DvdZAHp+jYbVTuTchzsV6q1txExdsY1yMNgUL0uat+UB?= =?iso-8859-1?Q?4i2AV70CixBwkoRCd1D5gAdAzIkiyq+evTabK1ga7N13ZXpuhbHMUJzAdp?= =?iso-8859-1?Q?vPWrTdLwNPHFq/FkeEwJYmf72wllPRZA7lE1EBiTntSgmbpGw3BB+/h8vV?= =?iso-8859-1?Q?bRwewHk74uYK6/buR/Ky3IAu7a+qMxivGoSLerKM3kG5cM1jkoGTrDc1/g?= =?iso-8859-1?Q?anYoeQ+BUA+dhvV8S0jmqr+/D7lODxHt+qVZ2ItEIj+FFYCgBZNa3XfTVA?= =?iso-8859-1?Q?KUu2rz0B45hzrVqKotkKi0r+67Jynfv+DywpPPn5bfs+xGH+8kM+jSd3Aa?= =?iso-8859-1?Q?Gi54u+q53hlWuPrA/brk6RwujT+W9eiZYCRrYNo7EmW/EAhrBbsp76nliy?= =?iso-8859-1?Q?SGXG9uUNBU5VXYffvq27HHrK1NOHs62ioMrMtEHnKAuhjGW/N+Fw7BnqLN?= =?iso-8859-1?Q?NWW6AA43RB0/uvbZjM8K9sIj8KvMpXrvFZauMPxmLispHgJDOJ3kiI7KmL?= =?iso-8859-1?Q?KRyztKvtVYGgKPxxxNrcm/I1U5BHGfSbIaEMY/Q4Dn9y1/NzwfdjzNE4bM?= =?iso-8859-1?Q?X9c9C3d9f+AqosqXAp+JGYebBCekK5DMA5SqroWqQfxuDComFuto/IO1V3?= =?iso-8859-1?Q?rJZcqqW6P51GdqCn/iZM29kPTOjB9P0f6XLgG32jYxSawFzeM4i51QG1dw?= =?iso-8859-1?Q?EUumkC8p74gcZ7i5iRNwzmgfr7FN4lFuyJ6ytyvEWiDHOw6tjhOqSRC9hd?= =?iso-8859-1?Q?+VIJqWjHmtjkjDKrkG8dXn2rRl6hMy+uC8UCDZ7kTG29ecjZ6iR97loOiZ?= =?iso-8859-1?Q?iEHNz7XKJe9GenTf/O67QkM2M04BVXrijccGwg6GB23wMP5+CvyHgPIEJw?= =?iso-8859-1?Q?TGSfaOBnl9fHQYYE/RnK6DDkobkRNq0nFFWHaBFaB4YGPuIGtFbxJJtBl3?= =?iso-8859-1?Q?ur39qBTmlMTDvS0mQjfe3JxNC6ss59QOqyuKA7hthW+pLsApm2Qj7Xb7KH?= =?iso-8859-1?Q?fWBHHI1nDC1Oq2NPQTUuHSsEfvkE4w54a6NqlK8dF00NwpOV6fBmtRXA?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 6ca41b3c-d2fe-4254-2aa8-08dbdebb5d18 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2023 11:27:30.7084 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: LLa6wC9JqrpsaEg8jgJsYK7gXq1CGw49+rzjFx6tJYGrLhoduCjOSU2nzI3us5WsMIw+u9ETTHafqhYZlc8fO+BMoa07ahihfbZJP5zCbRA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR11MB8171 X-OriginatorOrg: intel.com 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 On Mon, Nov 06, 2023 at 12:22:57PM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Monday, 6 November 2023 11.29 > > > > On Fri, Nov 03, 2023 at 09:19:53PM +0100, Morten Brørup wrote: > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > Sent: Friday, 3 November 2023 19.09 > > > > > > > > On Fri, Nov 03, 2023 at 06:31:30PM +0100, Morten Brørup wrote: > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > > > Sent: Friday, 3 November 2023 17.52 > > > > > > > > > > > > DPDK now has more optional libraries than mandatory ones, so > > invert > > > > the > > > > > > list stored in the meson.build file from the optional ones to > > the > > > > > > "always_enable" ones. As well as being a shorter list: > > > > > > > > > > > > * we can remove the loop building up the "always_enable" list > > > > > > dynamically from the optional list > > > > > > * it better aligns with the drivers/meson.build file which > > > > maintains an > > > > > > always_enable list. > > > > > > > > > > > > Signed-off-by: Bruce Richardson > > > > > > > > > > Excellent! > > > > > > > > > > It really shows how bloated DPDK CORE still is. I would like to > > see > > > > these go optional: > > > > > > > > > > > > > For some I agree, but we need to decide what optional really means. > > :-) > > > > > > > > For my mind, there are 3 (maybe 4) key components that need to be > > built > > > > for > > > > me to consider a build to be a valid DPDK one: > > > > * EAL obviously, > > > > * testpmd, because everyone seems to use it > > > > * l3fwd, becaues it's the most commonly referenced example and used > > for > > > > benchmarking, and build testing in test-meson-builds. (There are > > > > others, > > > > but they are pretty likely to build if l3fwd does!) > > > > * dpdk-test - I feel this should always be buildable, but for me > > it's > > > > the > > > > optional 4th component. > > > > > > > > Now, the obviously one to relax here is l3fwd, since it is just an > > > > example, > > > > but I wonder if that may cause some heartache. > > > > > > I don't consider any DPDK lib CORE just because the lib is used by > > testpmd and/or l3fwd. I agree that all libs should be included by > > default, so you can run testpmd, l3fwd, and other apps and examples. > > > > > > However, many libs are not needed for *all* DPDK applications, so I > > would like other apps to be able to build DPDK without superfluous > > libs. > > > > > > E.g. our StraightShaper CSP appliance is deployed at Layer 2, and > > doesn't use any of DPDK's L3 libs, so why should the DPDK L3 libs be > > considered CORE and thus included in our application? I suppose other > > companies are also using DPDK for other purposes than L3 routing, and > > don't need the DPDK L3 libs. > > > > > > Furthermore, I suppose that some Layer 3 applications use their own > > RIB/FIB/LPM libraries. Does OVS use DPDK's rib/fib/lpm libraries? > > > > > > > > > > > > > Overall, if we want to make more libs optional, I would start > > looking > > > > at > > > > l3fwd and making it a bit more modular. I previously made its > > support > > > > for > > > > eventdev optional, we should do the same for lpm and fib. Beyond > > that, > > > > we > > > > need to decide what core really means. > > > > > > Yes - defining CORE is the key to setting the goal here. > > > > > > In my mind, CORE is the minimum requirement to running an absolutely > > minimal DPDK application. > > > > > > A primary DPDK application would probably need to do some packet I/O; > > but it might be a simple layer two bridge, not using any of the L3 > > libs. > > > > > > And a secondary DPDK application might attach to a primary DPDK > > application only to work on its data structures, e.g. to collect > > statistics, but not do any packet processing, so that application > > doesn't need any of those libs (not even the ethdev lib). > > > > > > In reality, DPDK applications would probably need to build more libs > > than just CORE. But some application might need CORE + lib A, and some > > other application might need CORE + lib B. In essence, I don't want > > application A to drag around some unused lib B, and application B to > > drag around some unused lib A. > > > > > > It's an optimization only available a build time. Distros should > > continue providing all DPDK libs. > > > > > > There's also system testing and system attack surface to consider... > > all that bloat makes production systems more fragile and vulnerable. > > > > > > > I largely agree, though I do think that trying to split primary- > > secondary > > as having different builds could lead to some headaches, so I'd push > > any > > work around that further down the road. > > You are probably right that running a secondary process built differently than the primary process will cause an avalanche of new challenges, so I strongly agree to pushing it further down the road. I don't even know if there is any demand for such a secondary process. (We considered something like this for our application, but did something else instead.) Starting the secondary process with some additional run-time parameters will have to suffice. > > > > > Some thoughts on next steps: > > * From looks of my original list above, it appears the low-hanging > > fruit is > > largely gone, in terms of being able to turn off libs that have few > > dependencies, timer being one possible exception > > * I think it's worth looking into making l3fwd more modular so it can > > be > > build only with backend x or y or z in it. However, if agreeable, we > > can > > just start marking lpm and rib/fib libs as optional directly and have > > l3fwd not buildable in those cases. > > I agree with that. (It would also affect the variants of l3fwd.) > > > * For libs that depend on other libs for bits of functionality, we are > > getting into the realm of using ifdefs to start selectively removing > > bits. This is the not-so-nice bit as: > > > > - it makes it a lot harder to do proper build testing, as we now have > > to > > test with individual bits on and off. So long as we were just > > enabling/ > > disabling whole components, the build-minimal target was good > > enough to > > test we had a working build. With some libs partially depending on > > others - both of which may be disablable independently - our build > > test > > matrix just explodes. > > We could start without the matrix, and have the CI build just two or three variants: > 1. Everything (like now), > 2. CORE only, and > 3. CORE + all drivers with their dependencies. > > > - #ifdefs are just really, really ugly in the code, and make it far > > harder to maintain and manage. > > > > Therefore, I'm wondering if we can come up with some sort of neater > > solution here. > > > > For example, can we add support to the build system that allows some > > form > > of stubbing out of libraries when they are disabled? That would save > > the > > putting of ifdefs throughout other parts of DPDK and keep the > > management of > > the disabling of the library someway inside the library itself. One way > > to > > do this might be to have a "stub" folder inside a library folder, where > > that contains a minimal header file to be used to provide empty > > functions > > in case where the lib itself is disabled. Other, more interesting > > schemes, > > might involve the automatic creation - from the version.map file - of > > dummy > > functions for dependent libs to link against on build. > > If we stub out a library, we have to somehow ensure that no application/driver/library calls that library, expecting it to work, if the library disabled. Preferably, this should fail at build time. > My thinking was that any stubs would only be available internally at build time. For example, we could have libname.h and stubs/libname.h, where stubs/libname.h is never installed or exported for application use. We definitely cannot have stubs generally available to apps. /Bruce