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 8562B41B9F; Wed, 1 Feb 2023 14:16:01 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 733A742D0B; Wed, 1 Feb 2023 14:16:01 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 8839D42BC9 for ; Wed, 1 Feb 2023 14:15:59 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D717C5C0032; Wed, 1 Feb 2023 08:15:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 01 Feb 2023 08:15:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1675257357; x= 1675343757; bh=SyO07STutnHXwkCGuUkYXgRkBaXhvd8KBNGaKlNaC7s=; b=d EXqGMFFjaWyhK+teGcMi4OTrnUKfaS+h4SfZsV7LzgnvCRZRkua0Q3ElzXg69hWv D6MoRq8VPnbCd7nmy5Xjn85nH6WQD1WZ21VzTc23s/ObfNqv+NKaLfQPLIacp7Vn pCfZYVUPEkLnhskWHpea70lUQtnB4MfMTNEgpHGmwz4Tywn7+xSuBQdHDgJaUVTx P0dMEHxyTlYszcSY6KWxWnxUYF+z94BuBGEek18DQJj93RH5XiFCzFPXSQ9xHvZ4 zC2t6idIBKC9Nzr9UQtWIV5BzKzXyPW61OehwjR+rBtVH4+iO7xqSkKn7lO+OOWD zaCd5nWeNCxfKRQRmHDZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1675257357; x= 1675343757; bh=SyO07STutnHXwkCGuUkYXgRkBaXhvd8KBNGaKlNaC7s=; b=g zuz2QvBYhsdUtnG0Va9iP6f1RFgZlzxoUgPi3dYJC10J8kx1qoeD3PawwtCaivd9 vz58mTwqJMy/AFrZRRXjj0eGRvpGtPubeD3Kf4YP++7WOdbEFeJM3P9Wvjqmlg1B fF3TOvwvc7VkHkt6ncfZT3ag2vDlnviodjSL7PhEyMVL1w4gJKykYUrZcILH1XX8 OLoZ99UkhWbMtVeRMXFZ9DzGTyOJKqsEUVfC4e69mhSon8AQNoGAe9ANxuzO1aO0 vNJp2H6Bj6eR692yA4kcdBr65TYB7g3VviON6syxvkDaKvzvkC9r0NX35ym1u/kI PBN6WFasWSlJ2/6jHsTsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefiedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedvjeegvdevleelkefhlefhueetkeehkedvvefgjeefleeuffdt gedtjefgteefteenucffohhmrghinhepmhhitghrohhsohhfthdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhho nhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Feb 2023 08:15:55 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff , David Marchand , Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: bruce.richardson@intel.com, Ferruh Yigit , dev@dpdk.org, rmody@marvell.com, timothy.mcdaniel@intel.com, matan@nvidia.com, viacheslavo@nvidia.com, ruifeng.wang@arm.com, zhoumin@loongson.cn, drc@linux.vnet.ibm.com, kda@semihalf.com, konstantin.v.ananyev@yandex.ru, stephen@networkplumber.org, jerinj@marvell.com, honnappa.nagarahalli@arm.com Subject: Re: [PATCH v7 4/4] eal: add nonnull and access function attributes Date: Wed, 01 Feb 2023 14:15:54 +0100 Message-ID: <5353813.29KlJPOoH8@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D876E6@smartserver.smartshare.dk> References: <20221202153432.131023-1-mb@smartsharesystems.com> <3659208.MHq7AAxBmi@thomas> <98CBD80474FA8B44BF855DF32C47DC35D876E6@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 01/02/2023 13:50, Morten Br=F8rup: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 31/01/2023 19:26, Tyler Retzlaff: > > > On Tue, Jan 31, 2023 at 01:23:34PM +0100, Morten Br=F8rup wrote: > > > > > From: David Marchand [mailto:david.marchand@redhat.com] > > > > > On Wed, Jan 18, 2023 at 9:31 AM Morten Br=F8rup > > > > > wrote: > > > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > > > > On Tue, Jan 17, 2023 at 09:19:22AM +0100, Morten Br=F8rup > > > > > > > > > > + */ > > > > > > > > > > +#if defined(RTE_CC_GCC) || defined(RTE_CC_CLANG) > > > > > > > > > > +#define __rte_nonnull_params(...) \ > > > > > > > > > > + __attribute__((nonnull(__VA_ARGS__))) > > > > > > > > > > +#else > > > > > > > > > > +#define __rte_nonnull_params(...) > > > > > > > > > > +#endif > > > > > > > > > > + > > > > > > > > > > > > > > > > > > What do you think to have a namespace for macros like > > > > > > > > > '__rte_param_xxx', > > > > > > > > > so name macros as: > > > > > > > > > __rte_param_nonull > > > > > > > > > __rte_param_read_only > > > > > > > > > __rte_param_write_only > > > > > > > > > > > > > > > > > > No strong opinion, it just feels tidier this way > >=20 > > I tend to prefer this kind of namespace as well. > > Let's compare different naming proposals, > > taking into account what we already have for some annotations, > > and what is proposed to be added in this patch and David's patch > > for lock annotations. >=20 > David's lock annotations don't use a dedicated naming convention, but sim= ply replaces __attribute__(name(params)) with __rte_name(params), e.g.: >=20 > #define __rte_guarded_by(...) \ > __attribute__((guarded_by(__VA_ARGS__))) > #define __rte_exclusive_locks_required(...) \ > __attribute__((exclusive_locks_required(__VA_ARGS__))) > #define __rte_assert_exclusive_lock(...) \ > __attribute__((assert_exclusive_lock(__VA_ARGS__))) >=20 > This follows the existing convention in rte_common.h, which is easily rea= dable, because they directly translate to GCC attribute names, e.g.: >=20 > #define __rte_warn_unused_result __attribute__((warn_unused_result)) > #define __rte_always_inline inline __attribute__((always_inline)) > #define __rte_noinline __attribute__((noinline)) > #define __rte_hot __attribute__((hot)) > #define __rte_cold __attribute__((cold)) >=20 > I could follow this convention too, e.g.: >=20 > #define __rte_nonnull(...) __attribute__((nonnull(__VA_ARGS__))) >=20 > #define __rte_access_read_only(...) \ > __attribute__((access(read_only, __VA_ARGS__))) > #define __rte_access_write_only(...) \ > __attribute__((access(write_only, __VA_ARGS__))) >=20 [...] > > Longer macro names may be better for code readers. >=20 > You have a good point here, Thomas. It will also prevent using the access= mode attribute macros incorrectly. >=20 > Let's proceed with two macros (without and with size parameter) instead o= f the combined macros (with optional size parameter). >=20 > Referring to the existing convention in rte_common.h, what do you think a= bout naming the new macros as follows? >=20 > __rte_access_read_only(ptr_index) > __rte_access_read_only_size(ptr_index, size_index) >=20 > Or just: >=20 > __rte_read_only(ptr_index) > __rte_read_only_size(ptr_index, size_index) I think we don't need the word "access", so I prefer the second form. What about the proposal of having "param" in the name? We could also have "function" is some macro names. Does it bring a benefit? Please let's have a naming discussion with many opinions. > > > > > > > microsoft also has a tool & annotation vehicle for this type > > of > > > > > stuff. > > > > > > > this discussion has caused me to wonder what happens if we > > would > > > > > like > > > > > > > to > > > > > > > add additional annotations for other tools. just load on the > > > > > > > annotations > > > > > > > and expand them empty conditionally? > > > > > > > > > > > > > > https://learn.microsoft.com/en-us/cpp/code-quality/using-sal- > > > > > > > annotations-to-reduce-c-cpp-code-defects?view=3Dmsvc-170 > > > > > > > > > > > > > > anyway, just a thought. no serious response required here. > > > > > > > > > > > > Excellent input, Tyler! > > > > > > > > > > > > If we want DPDK to be considered truly cross-platform, and not > > treat > > > > > non-Linux/non-GCC as second class citizens, we need to discuss > > this. > > > > > > > > > > > > Microsoft's Source Code Annotation Language (SAL) seems very > > good, > > > > > based on its finer granularity than GCC's attributes (which in > > > > > comparison seem added as an afterthought, not cleanly structured > > like > > > > > SAL). I have only skimmed the documentation, but that is my > > immediate > > > > > impression of it. > > > > > > > > > > > > SAL uses a completely different syntax than GCC attributes, and > > > > > Microsoft happens to also use memcpy() as an example in the > > > > > documentation referred to: > > > > > > > > > > > > void * memcpy( > > > > > > _Out_writes_bytes_all_(count) void *dest, > > > > > > _In_reads_bytes_(count) const void *src, > > > > > > size_t count > > > > > > ); > > > > > > > > Stephen had bad experiences with SAL, so let's just consider the > > SAL memcpy() example a reference only, showing how the syntax of > > annotations can differ very much between build systems. > > > > > > yes, if we are in a position to use annotations today that work with > > > clang/gcc then let's do that even if they aren't compatible with SAL. > > > so long as they expand empty when not using clang/gcc we can defer > > discussion > > > about other tools like SAL. > >=20 > > Yes of course it must expand empty for compilers not supporting the > > annotation. > > Anyway I don't think we need to support all compilers with annotation. > > The main goal of annotation is to do more checks in the CI, > > so supporting one compiler should be enough. >=20 > There is also a secondary goal of increased performance. When the compile= r knows more about a function's behavior, it can optimize more around it. E= =2Eg. knowing that a function doesn't modify something already held in a re= gister (or other local memory) allows the compiler to reuse the local copy = (in the register) without fetching the original again. If we want to enable such performance optimizations with all compilers, we may have issues to find a common syntax. In general I am OK to try (best effort) but we should be reasonnable in case things are getting complex. [...] > > > > > 3d is the best option as it is not changing anything to what we > > were > > > > > doing so far: we evaluate the pros and cons of each > > annotations/tools, > > > > > case per case. > > > > > > > > Agree! > >=20 > > I am for 3d as well. > > We should focus on clang for using compilation checks. >=20 > Clang doesn't support the access mode attribute (yet?). It is only suppor= ted by GCC. OK > The CI also uses GCC, so let's not limit ourselves to what clang can do. = Using the access mode attribute with GCC is still useful for the CI to reve= al bugs. >=20 > I agree with you on the principle: We don't need to add the same bug-find= ing attributes to all compiler environments; adding them to one CI supporte= d compiler environment should suffice. >=20 > However, performance-enhancing attributes would be useful to support in m= ultiple compiler environments. >=20 > > Another question about annotations is how much we want to use them. > > I think we should use such check for critical code only. >=20 > Agree. And this includes some fast path code, where they might benefit pe= rformance. >=20 > > Adding annotations everywhere is not always worth making the code > > uglier. >=20 > I agree. I suppose Stephen stressed the same point when referring his exp= erience working with SAL. >=20 > It will be impossible to define a criteria for when to use or not use suc= h attributes, but we can probably agree on this: When adding new functions = to DPDK, adding such attributes is not a requirement. This should make it u= p to the contributor to decide if she wants to add them or not, which can b= e discussed on a case by case basis if the maintainer disagrees. Yes > This principle should limit the big discussions to which attributes we wa= nt to allow into rte_common.h; like these and the ones in David's lock anno= tation patch. OK