From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AA765A04AF; Fri, 21 Aug 2020 11:44:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AF6924CA6; Fri, 21 Aug 2020 11:44:21 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 56D412C02 for ; Fri, 21 Aug 2020 11:44:19 +0200 (CEST) IronPort-SDR: NOGFDyF4SbsdbNKziL+1mvykyjRObKGxgh+pkKS+X+37mfAJYvPMp0qWkixeF+0apYCTLXgHUX PRL4sgepAxLQ== X-IronPort-AV: E=McAfee;i="6000,8403,9719"; a="135035215" X-IronPort-AV: E=Sophos;i="5.76,335,1592895600"; d="scan'208";a="135035215" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Aug 2020 02:44:18 -0700 IronPort-SDR: NiPGOL4UIDvRZTzt1rm8ziEKJknuFRsep/boR0VHrKQFyDV6cK6pdNYj7vBd8HO57pqACS+rD2 cCQ0VJXwIBiQ== X-IronPort-AV: E=Sophos;i="5.76,335,1592895600"; d="scan'208";a="321205921" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.252.0.55]) ([10.252.0.55]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Aug 2020 02:44:17 -0700 To: Ed Czeck Cc: dev@dpdk.org, "Richardson, Bruce" , Shepard Siegel , John Miller References: <20200819153539.32698-1-ed.czeck@atomicrules.com> <20200819204514.22187-1-ed.czeck@atomicrules.com> <5715777c-a36a-8edd-7e06-2afebdef6c37@intel.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJsBBMBCgBWAhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEABQkKqZZ8FiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl6ha3sXGHZrczovL2tl eXMub3BlbnBncC5vcmcACgkQ+TPrQ98TYR8uLA//QwltuFliUWe60xwmu9sY38c1DXvX67wk UryQ1WijVdIoj4H8cf/s2KtyIBjc89R254KMEfJDao/LrXqJ69KyGKXFhFPlF3VmFLsN4XiT PSfxkx8s6kHVaB3O183p4xAqnnl/ql8nJ5ph9HuwdL8CyO5/7dC/MjZ/mc4NGq5O9zk3YRGO lvdZAp5HW9VKW4iynvy7rl3tKyEqaAE62MbGyfJDH3C/nV/4+mPc8Av5rRH2hV+DBQourwuC ci6noiDP6GCNQqTh1FHYvXaN4GPMHD9DX6LtT8Fc5mL/V9i9kEVikPohlI0WJqhE+vQHFzR2 1q5nznE+pweYsBi3LXIMYpmha9oJh03dJOdKAEhkfBr6n8BWkWQMMiwfdzg20JX0o7a/iF8H 4dshBs+dXdIKzPfJhMjHxLDFNPNH8zRQkB02JceY9ESEah3wAbzTwz+e/9qQ5OyDTQjKkVOo cxC2U7CqeNt0JZi0tmuzIWrfxjAUulVhBmnceqyMOzGpSCQIkvalb6+eXsC9V1DZ4zsHZ2Mx Hi+7pCksdraXUhKdg5bOVCt8XFmx1MX4AoV3GWy6mZ4eMMvJN2hjXcrreQgG25BdCdcxKgqp e9cMbCtF+RZax8U6LkAWueJJ1QXrav1Jk5SnG8/5xANQoBQKGz+yFiWcgEs9Tpxth15o2v59 gXK5Ag0EV9ZMvgEQAKc0Db17xNqtSwEvmfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ES YpV8QWj0xK4YM0dLxnDU2IYxjEshSB1TqAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4Ai bPtrHuIXWQOBECcVZTTOdZYGAzaYzxiAONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxD UQljeNvKYt1lZE/gAUUxNLWsYyTT+22/vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/ 3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35piVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVj sM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQI3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdc q9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYHfVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH7 1PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZqw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFB VOQOxCvwRG2QCgcJ/UTn5vlivul+cThi6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI 8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJlRr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYC GwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNhHwUCXqFrngUJCKxSYAAKCRD5M+tD3xNhH3YWD/9b cUiWaHJasX+OpiuZ1Li5GG3m9aw4lR/k2lET0UPRer2Jy1JsL+uqzdkxGvPqzFTBXgx/6Byz EMa2mt6R9BCyR286s3lxVS5Bgr5JGB3EkpPcoJT3A7QOYMV95jBiiJTy78Qdzi5LrIu4tW6H o0MWUjpjdbR01cnj6EagKrDx9kAsqQTfvz4ff5JIFyKSKEHQMaz1YGHyCWhsTwqONhs0G7V2 0taQS1bGiaWND0dIBJ/u0pU998XZhmMzn765H+/MqXsyDXwoHv1rcaX/kcZIcN3sLUVcbdxA WHXOktGTQemQfEpCNuf2jeeJlp8sHmAQmV3dLS1R49h0q7hH4qOPEIvXjQebJGs5W7s2vxbA 5u5nLujmMkkfg1XHsds0u7Zdp2n200VC4GQf8vsUp6CSMgjedHeF9zKv1W4lYXpHp576ZV7T GgsEsvveAE1xvHnpV9d7ZehPuZfYlP4qgo2iutA1c0AXZLn5LPcDBgZ+KQZTzm05RU1gkx7n gL9CdTzVrYFy7Y5R+TrE9HFUnsaXaGsJwOB/emByGPQEKrupz8CZFi9pkqPuAPwjN6Wonokv ChAewHXPUadcJmCTj78Oeg9uXR6yjpxyFjx3vdijQIYgi5TEGpeTQBymLANOYxYWYOjXk+ae dYuOYKR9nbPv+2zK9pwwQ2NXbUBystaGyQ== Message-ID: <0e7643a2-a480-0298-1262-bf88cf7b9318@intel.com> Date: Fri, 21 Aug 2020 10:44:13 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] net/ark: fix meson build X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 8/20/2020 4:41 PM, Ed Czeck wrote: > On Thu, Aug 20, 2020 at 7:16 AM Ferruh Yigit wrote: >> > ... >> >> Logging can be controlled in runtime, that is what we should use. >> In data path, we use compile time flags because of the performance issues. So OK >> to have 'CONFIG_RTE_LIBRTE_ARK_DEBUG_RX' & 'CONFIG_RTE_LIBRTE_ARK_DEBUG_TX' as >> compile time flag, but why having compile time flag for rest? > > Agreed. We'll remove most of these macro in the next commit pushing > the behavior > into run-time log control. > >>> >>> +Note that enabling debugging options may affect system performance. >>> +These options may be set by specifying them in CFLAG >>> +environment before the meson build set. E.g.:: >>> + >>> + export CFLAGS="-DARK_DEBUG_TRACE" >>> + meson build >>> + >> >> When you passed the flag as above, it is still global to all components in the >> DPDK, this is not just for ark. What is the motivation to remove the >> "RET_LIBRTE_" prefix? > > There are 2 issues here. > 1) With the makefile flow, users could add other configurations with > the documented > and recommended sed commands. I.e., > sed -ri 's/(CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE)=n/\1=y/' build/.config > The makefiles took care of everything from there. This no longer works with the > meson build flow. The solution is to set that macro passing it in the > CFLAG environment. > We're open to other recommendations. Yes compile time flags are harder to use with meson build system, and this is kind of intentional because of above mentioned reasons. It is possible to add compile time option as meson config option if we must, but that is not suggested, the intention is get rid of compile time flags as much as we can, and we were already very picky to accept new compile time flags to make build for some time. > 2) Is there an advantage of promoting a PMD macro to a global macro? > It seems to add to the noise of dpdk configuration and there are many > PMD specific macros throughout the code base. If CFLAG used to pass macros to multiple components, or if there is a bigger build environment that builds both application and DPDK, CFLAGS is common flag and I think better to keep the DPDK namespace for DPDK macros. At least let me say the way that I don't see the motivation to remove the DPDK namespace from macros. > >> >>> >>> Building DPDK >>> ------------- >>> diff --git a/drivers/net/ark/ark_logs.h b/drivers/net/ark/ark_logs.h >>> index 44aac6102..125583475 100644 >>> --- a/drivers/net/ark/ark_logs.h >>> +++ b/drivers/net/ark/ark_logs.h >>> @@ -6,14 +6,12 @@ >>> #define _ARK_DEBUG_H_ >>> >>> #include >>> -#include >>> - >>> >>> /* Configuration option to pad TX packets to 60 bytes */ >>> -#ifdef RTE_LIBRTE_ARK_PAD_TX >>> -#define ARK_TX_PAD_TO_60 1 >>> -#else >>> +#ifdef ARK_NOPAD_TX >>> #define ARK_TX_PAD_TO_60 0 >>> +#else >>> +#define ARK_TX_PAD_TO_60 1 >>> #endif >> >> So you don't want to convert this to runtime configuration. >> >> The point we are reducing compile time flags: >> 1) It forks the code paths and by time it leave not tested, even not compiled >> code paths which may cause rotten code by time. >> >> 2) Multiple code paths will lead deployment problems. When you deploy an >> application, you won't able to change the compile time configuration in customer >> environment and need to re-compile (most probably re-test) and re-deploy it. >> Also there is not easy way to figure out from binary in customer environment >> that with which compile time flags it has been built. >> >> Switching to CFLAGS="..." doesn't make above concerns go away and indeed it >> makes (1) worst since hides the config options within the driver. Previously it >> was possible to trigger each config option and do testing using scripts, now >> since config options are hidden in driver we can't do even that. >> >> Can you please detail why "ARK_TX_PAD_TO_60" is needed exactly? >> And can you please justify why it has to be compile time config option? >> > The need to pad packets is dependent on the underlying FPGA hardware > implementation which lies outside the control of our deliverables. Thus we > leave control up to our customer and how they deliver and deploy DPDK. This > needs to be a compile-time macro since the code executes within the > per-packet processing under rte_eth_tx_burst(). It is still possible to use runtime config by having two burst functions, one with padding and without padding support, which is selected based on provided runtime flag. Runtime parameter can provide the padding size. But agree that adds more complexity. > > We can change the macro to ARK_MIN_TX_PKTLEN, which should have zero > overhead when set to 0. (I'm assuming that compiles will remove if > (unsigned < 0) blocks.) Should this be an RTE_LIBRTE macro? How does > a user change this during compile? > >> <...> >> >>> @@ -11,3 +11,5 @@ sources = files('ark_ddm.c', >>> 'ark_pktgen.c', >>> 'ark_rqp.c', >>> 'ark_udm.c') >>> + >>> +install_headers('ark_ext.h') >>> >> >> Installing PMD header file is not required but this has an unique usage. >> >> Ark PMD is wrapper to the external shared library which should implement the >> functions that has prototypes in the 'ark_ext.h'. >> >> Since this header is not needed by users of the dpdk library, but needed by >> extension developers for the ark PMD, I think the header should not be installed. > > So is your recommendation that anyone developing an ark pmd extension > must have access to DPDK source, in addition to the installed code? > It seems like one include location is better than two. > Yes. I understand it makes PMD extension developer's life easy to have 'ark_ext.h' installed in system folders but I think it doesn't fit there. DPDK public headers are for application developers to use the DPDK APIs. 'ark_ext.h' is used by PMD developer to build PMD extension which is indeed can be taken as developing DPDK internal component. And if I understand correctly the a PMD extension is required per a bitstream for a Arkville device, so not really many developers affected from it. (Also the name prefix and the namespace of the symbols in the header is not suitable to be a public header, but this is something else.)