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 B51DCA04B5; Wed, 30 Sep 2020 18:49:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 989881D554; Wed, 30 Sep 2020 18:49:31 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 115B81D53F for ; Wed, 30 Sep 2020 18:49:28 +0200 (CEST) IronPort-SDR: bkjQlF3k9hknjqP+39LhTY66TCTwcVO2TiASw3mZfSDkxfqtpCt9O9qWibzJDG/IcSS7agZb9W 6uzLX94E2A6A== X-IronPort-AV: E=McAfee;i="6000,8403,9760"; a="247215414" X-IronPort-AV: E=Sophos;i="5.77,322,1596524400"; d="scan'208";a="247215414" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2020 09:49:27 -0700 IronPort-SDR: U0kXWXmWsGycVvibfIJAbCQ7xM1aw2HTsCYif4mJ8Yo0/jxLiXxSoVyGoEyQBd1t++ZYOGT/on 4F+/vMsqrqPQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,322,1596524400"; d="scan'208";a="498336981" Received: from irsmsx604.ger.corp.intel.com ([163.33.146.137]) by orsmga005.jf.intel.com with ESMTP; 30 Sep 2020 09:49:24 -0700 Received: from irsmsx601.ger.corp.intel.com (163.33.146.7) by IRSMSX604.ger.corp.intel.com (163.33.146.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 30 Sep 2020 17:49:23 +0100 Received: from irsmsx601.ger.corp.intel.com ([163.33.146.7]) by irsmsx601.ger.corp.intel.com ([163.33.146.7]) with mapi id 15.01.1713.004; Wed, 30 Sep 2020 17:49:23 +0100 From: "Richardson, Bruce" To: Thomas Monjalon CC: Andrew Rybchenko , "david.marchand@redhat.com" , "dev@dpdk.org" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility Thread-Index: AQHWjEiom/iz/TiyXUSkqBPSMIa88KltDzsAgAEHRYCACA89AIALU0ww Date: Wed, 30 Sep 2020 16:49:23 +0000 Message-ID: References: <20200916164429.244847-1-bruce.richardson@intel.com> <20200918084136.GD1583@bricha3-MOBL.ger.corp.intel.com> <2369022.OBMSpb71sc@thomas> In-Reply-To: <2369022.OBMSpb71sc@thomas> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-product: dlpe-windows dlp-reaction: no-action x-originating-ip: [163.33.253.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, September 23, 2020 1:46 PM > To: Richardson, Bruce > Cc: Andrew Rybchenko ; > david.marchand@redhat.com; dev@dpdk.org; Yigit, Ferruh > > Subject: Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros fo= r > compatibility >=20 > 18/09/2020 10:41, Bruce Richardson: > > On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: > > > On 9/16/20 7:44 PM, Bruce Richardson wrote: > > > > * We still have inconsistencies in our driver macro and naming > templates. > > > > This is just a nice-to-have, but if people are ok with generally > having a > > > > breakage in our macro defines, we could clean this up a lot > further. > > > > Notice how 'net', 'regex' and 'vdpa' have '_PMD' at the end, > while most > > > > others have it before the name. Notice also that many device > classes have > > > > the class at the end of the template, while bbdev has it in the > middle. > > > > $ git grep config_flag_fmt -- drivers/*/meson.build > > > > drivers/baseband/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_PMD_BBDEV_@0@' > > > > drivers/bus/meson.build:config_flag_fmt =3D 'RTE_LIBRTE_@0@_BUS' > > > > drivers/common/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_@0@_COMMON' > > > > drivers/compress/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_PMD_@0@' > > > > drivers/crypto/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_PMD_@0@' > > > > drivers/event/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_PMD_@0@_EVENTDEV' > > > > drivers/mempool/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_@0@_MEMPOOL' > > > > drivers/net/meson.build:config_flag_fmt =3D 'RTE_LIBRTE_@0@_PMD' > > > > drivers/raw/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_PMD_@0@_RAWDEV' > > > > drivers/regex/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_@0@_PMD' > > > > drivers/vdpa/meson.build:config_flag_fmt =3D > 'RTE_LIBRTE_@0@_PMD' > > > > > > As a generic direction I would vote for standard names which are > > > based on directory structure: > > > - RTE_LIBRTE_ETHDEV > > > - RTE_DRIVER_NET_SFC > > > - RTE_DRIVER_COMMON_MLX5 > > > - RTE_DRIVER_BUS_PCI >=20 > I would prefer RTE_LIB_ETHDEV (instead of LIBRTE). > If we plan to rework all flags, I would even prefer > - DPDK_LIB_ETHDEV > - DPDK_DRIVER_BUS_PCI Since everything else in DPDK uses an RTE prefix, I think it might be sensi= ble to keep that here too: * RTE_LIB_ETHDEV * RTE_PMD_BUS_PCI * RTE_PMD_NET_IXGBE * RTE_PMD_CRYPTO_KASUMI etc. > > Definite +1, and it would be good if we standardized the .so names like > > that too. >=20 > +1 to align .so names for clarity. >=20 I'd really like this, but need to see the implications for any drivers whic= h may be multi-function, like QAT which has a single .so file. > > The open question is how much backward compatibility needs to be > maintained > > for macros (and also too for .so names)? With this patchset, I've aimed > > very much to keep strict compatibility for now. >=20 > As David said, the compatibility is mostly for apps using driver-specific > API. > We could also consider that the compatibility break was announced > as part of the makefile removal. > In any case, it is not ABI sensitive, so no need to wait 21.11. > If choosing between a compilation flag breakage in 21.02 or 20.11, > I would prefer 20.11 where legacy build system is removed. >=20 > About LTS, we may want to have some patches targetted to 18.11 and 19.11, > to allow a transparent switch between make and meson. >=20 Any more thoughts on this?=20 Any change to standardize the library names is going to have to be done in = 20.11 if it's to be done at all, since that would be an ABI break. I'd tend= towards only changing the defines for 21.02, but if lots of other things a= re changing too, perhaps it's not worthwhile waiting. /Bruce