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 5376442FC8; Thu, 3 Aug 2023 18:41:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D8D7E40C35; Thu, 3 Aug 2023 18:41:03 +0200 (CEST) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [24.116.100.90]) by mails.dpdk.org (Postfix) with ESMTP id 07ABB406BA for ; Thu, 3 Aug 2023 18:41:01 +0200 (CEST) Received: from smtpclient.apple (macbook3-8.redfish-solutions.com [192.168.8.12] (may be forged)) (authenticated bits=0) by mail.redfish-solutions.com (8.17.1/8.16.1) with ESMTPSA id 373Gf0Ks072298 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Aug 2023 10:41:00 -0600 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Drivers, architectures, processor families, etc. From: Philip Prindeville In-Reply-To: <20230802154759.0befb39c@hermes.local> Date: Thu, 3 Aug 2023 10:40:47 -0600 Cc: dev@dpdk.org Content-Transfer-Encoding: quoted-printable Message-Id: <783A7C11-9B33-49B1-913D-1D9D5C6B6688@redfish-solutions.com> References: <45384262-9744-4975-B5FB-D5D26608DF5B@redfish-solutions.com> <20230802154759.0befb39c@hermes.local> To: Stephen Hemminger X-Mailer: Apple Mail (2.3731.600.7) X-Scanned-By: MIMEDefang 3.4.1 on 192.168.8.3 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 Aug 2, 2023, at 4:47 PM, Stephen Hemminger = wrote: >=20 > On Wed, 2 Aug 2023 15:49:54 -0600 > Philip Prindeville wrote: >=20 >> Hi, >>=20 >> I'm trying to come up with some Kconfig logic for OpenWRT packaging = to help users select the right build options for their hardware. >>=20 >> Most OpenWRT developers typically cross-compile, so we obviously = can't rely on detection on the build host as that's rarely the same as = the target machine. >>=20 >> Looking in the DPDK repo, I don't see any description of the = available architectures, drivers, etc. and what I had seen previously = was (if I remember) only for x86_64 hardware, and even that I can't seem = to locate again. >>=20 >> Would it make sense to put some of these definitions into the repo = itself, so that when new drivers are added, that stands out (at least in = the commit logs) and we can capture the permutations of what driver goes = with which SoC on what architecture, etc? >>=20 >> Thanks, >>=20 >> -Philip >>=20 >=20 > DPDK now uses meson which by default builds everything available on = the build architecture. > There is intentionally no way to disable drivers, you can disable some = libraries though. The issue I'm trying to resolve is that if you're building for SoC Xyzzy = that includes an on-chip NIC, then that driver should *only* ever be = selectable when building for that SoC. There's no point if generating (or packaging) combinations of platform + = driver that aren't viable. Are you suggesting that we just select the architecture, and let the = available drivers fall out of that?