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 28814A00C4; Mon, 14 Feb 2022 19:41:01 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F0A6240DDA; Mon, 14 Feb 2022 19:41:00 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 210AE4067E for ; Mon, 14 Feb 2022 19:40:59 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 6D1BD20B9C2C; Mon, 14 Feb 2022 10:40:58 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6D1BD20B9C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1644864058; bh=b1rEw2aNO2qrjv7LbHi6cu9M8+vb2pIwN7TdZ1WzQMI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rp90fD/SJQJBi/nQahvrZCM7R2yO0BNaBcIRFlszTCWr10rQY+jAhVLEch6Iy7sy8 IZvRvkomz4AduFq5PunLqoRHAicw0+EeBd2OILMbRhbthmQmD6lwLwfBgoipMog6wa 7jhT7VqTORHKbFTTM9GX/Aks0c8WCzQQOSKogtnc= Date: Mon, 14 Feb 2022 10:40:58 -0800 From: Tyler Retzlaff To: Stephen Hemminger Cc: Thomas Monjalon , Bruce Richardson , dev@dpdk.org, ocardona@microsoft.com, roretzla@microsoft.com, david.marchand@redhat.com, ferruh.yigit@intel.com Subject: Re: out of tree driver builds broken with C++ Message-ID: <20220214184058.GB28066@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20220214091350.GA2793@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20220214092435.6fb6964e@hermes.local> <58747087.matp6XCIr4@thomas> <20220214102120.2bbd22e2@hermes.local> <20220214183224.GA28066@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220214183224.GA28066@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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, Feb 14, 2022 at 10:32:24AM -0800, Tyler Retzlaff wrote: > On Mon, Feb 14, 2022 at 10:21:20AM -0800, Stephen Hemminger wrote: > > On Mon, 14 Feb 2022 18:49:48 +0100 > > Thomas Monjalon wrote: > > > > > 14/02/2022 18:t24, Stephen Hemminger: > > > > On Mon, 14 Feb 2022 15:03:43 +0000 > > > > Bruce Richardson wrote: > > > > > > > > > On Mon, Feb 14, 2022 at 11:43:35AM +0000, Bruce Richardson wrote: > > > > > > On Mon, Feb 14, 2022 at 12:19:24PM +0100, Thomas Monjalon wrote: > > > > > > > 14/02/2022 11:45, Bruce Richardson: > > > > > > > > On Mon, Feb 14, 2022 at 10:22:08AM +0100, Thomas Monjalon wrote: > > > > > > > > > 14/02/2022 10:13, Tyler Retzlaff: > > > > > > > > > > while the driver api is "internal" we agreed some time ago that drivers > > > > > > > > > > could be built external to the dpdk tree. by enabling the meson setup > > > > > > > > > > option -Denable_driver_sdk=true. > > > > > > > > > > > > > > > > > > > > it was agreed that the driver api was internal and would attract no > > > > > > > > > > binary compatibility support which was fine. this change has now > > > > > > > > > > imposed a further restriction that out of tree drivers have to be > > > > > > > > > > authored in C only as non-C++ compatible code will invariably leak into > > > > > > > > > > the internal structures. > > > > > > > > > > > > > > > > > > > > you won't allow us to build C++ drivers in the dpdk tree and it seems > > > > > > > > > > now you are preventing building of C++ drivers outside of the tree too. > > > > > > > > > > > > > > > > > > That's the problem of non-written assumptions, they are unknown or forgotten. > > > > > > > > > Did we agree to support out-of-tree drivers in C++? > > > > > > > > > > > > > > > > > > We really need to make things clear and written in documentation. > > > > > > > > > > > > > > > > > > > could we please re-evaluate this. > > > > > > > > > > > > > > > > > > Yes we can re-evaluate. > > > > > > > > > What is the list of impacted files? > > > > > > > > > > > > > > > > > Hacking meson files a bit, the list of SDK header files is reported as below. > > > > > > > > > > > > > > > > /Bruce > > > > > > > > > > > > > > > > Message: SDK headers: > > > > > > > > Message: ethdev_driver.h > > > > > > > > Message: ethdev_pci.h > > > > > > > > Message: ethdev_vdev.h > > > > > > > > Message: cryptodev_pmd.h > > > > > > > > Message: eventdev_pmd.h > > > > > > > > Message: eventdev_pmd_pci.h > > > > > > > > Message: eventdev_pmd_vdev.h > > > > > > > > Message: eventdev_trace.h > > > > > > > > Message: event_timer_adapter_pmd.h > > > > > > > > Message: rte_dmadev_pmd.h > > > > > > > > Message: vdpa_driver.h > > > > > > > > > > > > > > I see no harm in supporting C++ include of these headers. > > > > > > > Any objection? > > > > > > > > > > > > > > Could we have a test in chkincs for the SDK headers? > > > > > > > > > > > > > Yes. It may make things a little more complicated, though, as it seems > > > > > > these headers also have a tendency to rely on some driver headers - > > > > > > specifically bus driver headers. > > > > > > > > > > > > > > > > Working on a patch to add these to checks. However, just running a c++ > > > > > compile does not check for valid 'extern "C"' blocks. Adding the following > > > > > to chkincs/meson.build as a basic sanity check throws up a larger list of > > > > > files to be looked at. > > > > > > > > > > Diff: > > > > > > > > > > +# check for extern C in files, since this is not detected as an error by the compiler > > > > > +grep = find_program('grep', required: false) > > > > > +if grep.found() > > > > > + errlist = run_command([grep, '--files-without-match', '^extern "C"', dpdk_chkinc_headers], > > > > > + check: true, capture: true).stdout().split() > > > > > + if errlist != [] > > > > > + error('Files missing C++ \'extern "C"\' guards:\n- ' + '\n- '.join(errlist)) > > > > > + endif > > > > > +endif > > > > > + > > > > > > > > > > Output: > > > > > ../buildtools/chkincs/meson.build:45:8: ERROR: Problem encountered: Files missing C++ 'extern "C"' guards: > > > > > - /home/bruce/dpdk.org/lib/telemetry/rte_telemetry.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_bitops.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_branch_prediction.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_compat.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_hypervisor.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_keepalive.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_pci_dev_feature_defs.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_pci_dev_features.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_time.h > > > > > - /home/bruce/dpdk.org/lib/eal/include/rte_trace_point_register.h > > > > > - /home/bruce/dpdk.org/lib/eal/linux/include/rte_os.h > > > > > - /home/bruce/dpdk.org/lib/ethdev/rte_dev_info.h > > > > > - /home/bruce/dpdk.org/lib/ethdev/ethdev_driver.h > > > > > - /home/bruce/dpdk.org/lib/ethdev/ethdev_pci.h > > > > > - /home/bruce/dpdk.org/lib/ethdev/ethdev_vdev.h > > > > > - /home/bruce/dpdk.org/lib/metrics/rte_metrics_telemetry.h > > > > > - /home/bruce/dpdk.org/lib/acl/rte_acl_osdep.h > > > > > - /home/bruce/dpdk.org/lib/bpf/bpf_def.h > > > > > - /home/bruce/dpdk.org/lib/compressdev/rte_compressdev_internal.h > > > > > - /home/bruce/dpdk.org/lib/cryptodev/cryptodev_pmd.h > > > > > - /home/bruce/dpdk.org/lib/eventdev/rte_event_ring.h > > > > > - /home/bruce/dpdk.org/lib/eventdev/eventdev_pmd.h > > > > > - /home/bruce/dpdk.org/lib/eventdev/eventdev_pmd_pci.h > > > > > - /home/bruce/dpdk.org/lib/eventdev/eventdev_pmd_vdev.h > > > > > - /home/bruce/dpdk.org/lib/kni/rte_kni_common.h > > > > > - /home/bruce/dpdk.org/lib/vhost/rte_vdpa.h > > > > > - /home/bruce/dpdk.org/lib/vhost/rte_vhost_async.h > > > > > - /home/bruce/dpdk.org/lib/vhost/rte_vhost_crypto.h > > > > > - /home/bruce/dpdk.org/lib/vhost/vdpa_driver.h > > > > > > > > > > Regards, > > > > > /Bruce > > > > > > > > The actual C++ guards are small and have no impact therefore we > > > > should accept patches as needed. Having more guards than needed is > > > > just noise. > > > > > > > > But the responsibility of telling DPDK project where they are required > > > > should fall to any out-of-tree users who care. > > > > > > Sorry Stephen I don't understand. > > > Please could you rephrase your comment? > > > > Since there are no in-tree DPDK drivers that use C++ it is an extra > > effort to add infrastructure to test if headers are broken. As new > > features get added to the DPDK, it doesn't make sense for the upstream > > DPDK to guarantee that no driver API changed in a way that breaks C++. > > But if a breakage happens in C++ driver, the upstream DPDK is willing > > to accept patches to fix it. > > that is completely untenable. to have a policy where the consumers using > c++ have to detect the non-compatible changes and then react by > submitting patches to fix upstream is overly burdensome. > > it is far less overhead to prevent the non-compatible code creaping into > the headers in the first place rather than pushing it down to the users > of dpdk. s/creaping/creeping/ additionally on the topic of extra effort you should consider the perpetual submission and review of patches has non-zero overhead.