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 1B1CA42A83; Tue, 16 May 2023 21:19:23 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ED35C406B6; Tue, 16 May 2023 21:19:22 +0200 (CEST) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [24.116.100.90]) by mails.dpdk.org (Postfix) with ESMTP id 856994003C for ; Tue, 16 May 2023 21:19:20 +0200 (CEST) Received: from smtpclient.apple (macbook3-3.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 34GJJJrm582533 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 16 May 2023 13:19:19 -0600 From: Philip Prindeville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: DPDK packaging and OpenWrt Message-Id: <60A57C56-D30C-4B0F-BAE9-01BA6FD16E66@redfish-solutions.com> Date: Tue, 16 May 2023 13:18:40 -0600 To: dev@dpdk.org X-Mailer: Apple Mail (2.3731.500.231) X-Scanned-By: MIMEDefang 3.3 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 Hi, I'm a packaging maintainer for some of the OpenWrt ancillary packages, = and I'm looking at upstreaming DPDK support into OpenWrt. Apologies in = advance if this is a bit dense (a brain dump) or hops between too many = topics. I was looking at what's been done to date, and it seems there are a few = shortcomings which I hope to address. Amongst them are: * getting DPDK support into OpenWrt's main repo for the kmod's and into = the packages repo for the user-space support; * making DPDK supported on all available architectures (i.e. agnostic, = not just x86_64 specific); * integrating into the OpenWrt "make menuconfig" system, so that editing = packages directly isn't required; * supporting cross-building and avoiding the [flawed] assumption that = the micro-architecture of the build server is in any way related to the = processor type of the target machine(s); * integration into the OpenWrt CI/CD tests; * making the kernel support as secure/robust as possible (i.e. avoiding = an ill-behaved application taking down the kernel, since this is a = firewall after all); * avoiding conflict with other existing module or package functionality; * avoiding, to the extent possible, introducing one-off toolchain = dependencies that unnecessarily complicate the build ecosystem; To this end, I'm asking the mailing list for guidance on the best = packaging practices that satisfy these goals. I'm willing to do = whatever heavy lifting that's within my ability. I have some related questions. 1. OpenWrt already bakes "vfio.ko" and "vfio-pci.ko" here: = https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/module= s/virt.mk#L77-L117 but does so with "CONFIG_VFIO_PCI_IGD=3Dy", which seems to be = specifically for VGA acceleration of guests in a virtualized = environment. That seems to be an odd corner case, and unlikely given = that OpenWrt almost always runs on headless hardware. Should this be = reverted? 2. "vfio.ko" is built with "CONFIG_VFIO_NOIOMMU=3Dy", which seems = insecure. Can this be reverted? 3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of = a misbehaving application? My understanding is that it's only needed on = SR-IOV hardware where MSI/MSI-X interrupts aren't supported: is there = even any current hardware that doesn't support MSI/MSI-X? Or am I = misunderstanding the use case? 4. Can most functionality be achieved with VFIO + IOMMU support? 5. I've seen packaging for the "iommu_v2.ko" module done here: = https://github.com/k13132/openwrt-dpdk/blob/main/packages/kmod-iommu_v2/Ma= kefile#L22-L42 Is this potentially useful? What platforms/architectures use this = driver? 6. Hand editing a wrapper for dpdk.tar.gz is a non-starter. I'd rather = add Kconfig adornments to OpenWrt packaging for the wrapper so that = options for "-Denable_drivers=3D" and "-Dcpu_instruction_set=3D" can be = passed in once global build options for OpenWrt have been selected. = Defaulting the instruction set to the build host is going to be wrong at = least some of the time, if not most of the time. For x86_64, what is a = decent compromise for a micro-architecture that will build and run on = most AMD and Intel hardware? What's a decent baseline for an ARM64 = micro-architecture that will build and run on most ARM hardware? 7. Many embedded systems don't build with glibc because it's too bloated = (and because critical fixes sometimes take too long to roll out), and = instead use MUSL, eglibc, or uClibc (although the last one seems to be = waning). Only glibc supports from what I can tell. Can = broader support for other C runtimes be added? Can RTE_BACKTRACE be = made a parameter or conditionally defined based on the runtime headers? = (autotools would be and HAVE_EXECINFO_H would be really handy here, but = I'm not sure how to make this play well with meson/ninja, and truth be = told I'm an old school Makefile + autotools knuckle-dragger). 8. How do I validate that DPDK is properly being built with the = cross-tools and not native tools? Even when building x86_64 targets on = an x86_64 build host, we end up using a custom toolchain and not the = "native" compiler that comes with the distro. 9. What is the parity between AMD64 and ARM64? Do both platforms offer = equal functionality and security, if not performance? 10. Who else is using DPDK with OpenWrt that is open to collaboration? 11. What is the user-space TCP/IP stack of choice (or reference) for use = with DPDK? Thanks, -Philip