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 A5787432D0; Wed, 8 Nov 2023 09:19:40 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2A388427E8; Wed, 8 Nov 2023 09:19:40 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 84F6F402C2 for ; Wed, 8 Nov 2023 09:19:39 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 5C1A9200F4; Wed, 8 Nov 2023 09:19:39 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC acceptable handling of VLAs across toolchains X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Nov 2023 09:19:37 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFED@smartserver.smartshare.dk> In-Reply-To: <20231108032504.GB19492@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC acceptable handling of VLAs across toolchains Thread-Index: AdoR8yza8oZeCZ8zSluLcQQENOKYCQAIkePA References: <20231107193220.GA15232@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20231107183114.330c2d8e@hermes.local> <20231108032504.GB19492@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Stephen Hemminger" Cc: 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 > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Wednesday, 8 November 2023 04.25 >=20 > On Tue, Nov 07, 2023 at 06:31:14PM -0800, Stephen Hemminger wrote: > > On Tue, 7 Nov 2023 11:32:20 -0800 > > Tyler Retzlaff wrote: > > > > > hi folks, > > > > > > i'm seeking advice. we have use of VLAs which are now optional in > > > standard C. some toolchains provide a conformant implementation = and > msvc > > > does not (and never will). Just so everyone is on the same page... this is a VLA (Variable Length = Array): void f(int n) { int v[n]; // VLA: its size is determined at run-time. } > > > > > > we seem to have a few options, just curious about what people = would > > > prefer. > > > > > > * use alloca VLAs have the advantage that they are allocated on the stack, which = usually means that the memory is already present in the CPU's L1 cache = (or L2 cache if using a larger block of memory). It seems alloca() also allocates on the stack, so alloca() should = provide similar performance. > > > > > > * use dynamically allocated storage This would probably have lower performance than alloca() due to using = "cold" memory, as opposed to memory on the stack. And it needs to be explicitly freed again, which is somewhat annoying, = compared to automatically freed memory. > > > > > > * conditional compiled code where the msvc leg uses one of the > previous > > > two options I agree with Stephen on this: Whatever VLA alternative we choose for = MSVC, other compilers can use that too. There is no need for #ifdefs to = keep VLAs for other compilers. > > > > > > i'll leave it simple for now, i'd like to hear input rather than > provide > > > a recommendation for now. > > > > > > > VLAs are a bug magnet. Best to avoid them, most code doesn't need > them. >=20 > just in case i didn't clarify properly early when i said they were > optional i meant they used to be non-optional. VLAs were standard in C99, and became optional in C11. > the intent of the RFC > here isn't that i want to add more but i'm looking for the best > approach > to getting rid of the ones we already have. > > The one common use case is code that accepts a burst of packets. > > But such code could easily have an upper bound if necessary. Exactly! I suggest that we forbid the use of VLAs. For fast path code, constant-size arrays should be strongly recommended. For non-fast path code, use alloca() or whatever VLA alternative is = convenient on a case-by-case basis. Perhaps checkpatches can detect the use of VLAs? Or it could be updated = to check for them. For reference, VLAs are forbidden in the Linux Kernel [1]. A good excuse = for also forbidding them in DPDK. ;-) [1]: https://www.phoronix.com/news/Linux-Kills-The-VLA > > > > Please don't add more to the maze of #ifdef's >=20 > thanks! i'll keep this in mind.