From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 166EE43E24; Sun, 7 Apr 2024 19:03:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7EB934029A; Sun, 7 Apr 2024 19:03:09 +0200 (CEST) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by mails.dpdk.org (Postfix) with ESMTP id 3A83D4026F for <dev@dpdk.org>; Sun, 7 Apr 2024 19:03:08 +0200 (CEST) Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-6ecf406551aso2456401b3a.2 for <dev@dpdk.org>; Sun, 07 Apr 2024 10:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712509387; x=1713114187; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=pC5+C6YXc6mufP/eUEWraWBTTUCYxKHB97kvlHd8RIY=; b=yLNVW8mfJ+7mmVgn6gVyFwzceNxC0G7HEkHMJMv6PdCdyko4qPE2Yo+cjPQS2vIEDS S1RD2OcpzLyUdzH9wR+zqhyrLgv1MVr5PeH37m2JoMtyDDiG9I3Bi8P6z6VsImlkaJZR 2Ly6+fkGu7EAKTNMzvifekJm8OIcnm5M9weAcmN2blrPRNfq2jIRO/ueOq/7wYu9LDye Li34/5GRzbmyzUxL6we6Hqws0HIfQZ12tLKG8ZFbjtmH0jR0LB2lrwSp81JVCwCLGhNd Ozo3qD/GsjXT19bCzG/+H4kLuNIp/O0/ulwfUMv3VLP22WXVRhNALkE4fUFBoukdwJuG 1GbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712509387; x=1713114187; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pC5+C6YXc6mufP/eUEWraWBTTUCYxKHB97kvlHd8RIY=; b=eMOZaMToSuYDRT0hBFY/MtqqnR2IKj6bYuK5jPZWO+HUvQe9C6aTSHKGT6WseBuOxI QzSvsigjy8G62fLNnW8FlBd2EomhxmEpu2N7pfwS7VqCRa9b8TONct7mBOy1TojoNCHy CYi9AhOV1cU8/D7m7gEE8o4bUh2Ey+ed3zQKqBKCCaHYtQVujpjskjAvEMOArhZwftim YEGGBqdoG++TJMed/c5gooTi7ip7AMoYlmR3gyJWOutOr/pusZR3q5jDZP0N4fXYbzEB 2UKN3I9uGqX1FDdSl4I8J4KHmTBFrXhYAOocB8igRogN0oew2K0RruqM/NXn9xisO8oZ smIQ== X-Forwarded-Encrypted: i=1; AJvYcCUajGIKyq+juH0se/9NjsVpDrindFIwl0J58ARosBbnc6gQikzrCqOx0/5kS2xI8fm2Dhmlts5D5JkPy/M= X-Gm-Message-State: AOJu0YwHlCSyMb6BFwchdHJOprC/RWxv8h4/VZQWnlDRnjZcqMSAqOjg wbZ4V58W3xlCHBZaInJYyrhnSHVV8BiWvXZfpspMViQhPPBJwRHmeKGHBYIqqpE= X-Google-Smtp-Source: AGHT+IHWyWPvKqizlVmPUBRpDjmFRkxSEZHaAjcPqAEP728dfk+l+tYmrg2sMSEYAM0eXdjrDlgRRA== X-Received: by 2002:a05:6a21:4982:b0:1a7:2d39:51cf with SMTP id ax2-20020a056a21498200b001a72d3951cfmr6911349pzc.26.1712509387280; Sun, 07 Apr 2024 10:03:07 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id h11-20020a63210b000000b005dcc8a3b26esm4707223pgh.16.2024.04.07.10.03.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Apr 2024 10:03:07 -0700 (PDT) Date: Sun, 7 Apr 2024 10:03:06 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com> Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= <hofors@lysator.liu.se>, "Tyler Retzlaff" <roretzla@linux.microsoft.com>, <dev@dpdk.org>, "Bruce Richardson" <bruce.richardson@intel.com>, "Thomas Monjalon" <thomas@monjalon.net> Subject: Re: [PATCH 0/4] RFC samples converting VLA to alloca Message-ID: <20240407100306.36c9688f@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F379@smartserver.smartshare.dk> References: <20231107193220.GA15232@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <1712250913-1977-1-git-send-email-roretzla@linux.microsoft.com> <adb81b30-bece-416b-a233-b08873d196f6@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F379@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Sun, 7 Apr 2024 13:07:06 +0200 Morten Br=C3=B8rup <mb@smartsharesystems.com> wrote: > > From: Mattias R=C3=B6nnblom [mailto:hofors@lysator.liu.se] > > Sent: Sunday, 7 April 2024 11.32 > >=20 > > On 2024-04-04 19:15, Tyler Retzlaff wrote: =20 > > > This series is not intended for merge. It insteat provides examples = =20 > > of =20 > > > converting use of VLAs to alloca() would look like. > > > > > > what's the advantages of VLA over alloca()? > > > > > > * sizeof(array) works as expected. > > > > > > * multi-dimensional arrays are still arrays instead of pointers to > > > dynamically allocated space. this means multiple subscript syntax > > > works (unlike on a pointer) and calculation of addresses into =20 > > allocated =20 > > > space in ascending order is performed by the compiler instead of = =20 > > manually. =20 > > > =20 > >=20 > > alloca() is a pretty obscure mechanism, and also not a part of the C > > standard. VLAs are C99, and well-known and understood, and very > > efficient. =20 >=20 > The RFC fails to mention why we need to replace VLAs with something else: >=20 > VLAs are C99, but not C++; VLAs were made optional in C11. >=20 > MSVC doesn't support VLAs, and is not going to: > https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriv= ing-in-msvc/#variable-length-arrays >=20 >=20 > I dislike alloca() too, and the notes section in the alloca(3) man page e= ven discourages the use of alloca(): > https://man7.org/linux/man-pages/man3/alloca.3.html >=20 > But I guess alloca() is the simplest replacement for VLAs. > This RFC patch series opens the discussion for alternatives in different = use cases. >=20 The other issue with VLA's is that if the number is something that can be e= xternally input, then it can be a source of stack overflow bugs. That is why the Linu= x kernel has stopped using them; for security reasons. DPDK has much less of a secur= ity trust domain. Mostly need to make sure that no data from network is being used to compute VLA size.