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 C944043DE9; Tue, 9 Apr 2024 10:28:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9EF6B402C0; Tue, 9 Apr 2024 10:28:52 +0200 (CEST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id DAEBF402B9; Tue, 9 Apr 2024 10:28:50 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VDJry5KgYz6K92N; Tue, 9 Apr 2024 16:24:02 +0800 (CST) Received: from frapeml100008.china.huawei.com (unknown [7.182.85.131]) by mail.maildlp.com (Postfix) with ESMTPS id 5B8211400CA; Tue, 9 Apr 2024 16:28:48 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100008.china.huawei.com (7.182.85.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 9 Apr 2024 10:28:48 +0200 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.035; Tue, 9 Apr 2024 10:28:48 +0200 From: Konstantin Ananyev <konstantin.ananyev@huawei.com> To: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>, "Tyler Retzlaff" <roretzla@linux.microsoft.com>, Stephen Hemminger <stephen@networkplumber.org>, "techboard@dpdk.org" <techboard@dpdk.org> CC: =?iso-8859-1?Q?Mattias_R=F6nnblom?= <hofors@lysator.liu.se>, "dev@dpdk.org" <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 Thread-Topic: [PATCH 0/4] RFC samples converting VLA to alloca Thread-Index: AQHahrO8mqsV6ha1EkmL480J0CFr3rFcbeUAgAAaoACAAGN3AIABd3+AgAAHW4CAATbNUA== Date: Tue, 9 Apr 2024 08:28:48 +0000 Message-ID: <09aac29da90a499ebfc16493e9942bf6@huawei.com> 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> <20240407100306.36c9688f@hermes.local> <20240408152703.GA25804@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35E9F380@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F380@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.138.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Monday, 8 April 2024 17.27 > > > > For next technboard meeting. > > > > On Sun, Apr 07, 2024 at 10:03:06AM -0700, Stephen Hemminger wrote: > > > On Sun, 7 Apr 2024 13:07:06 +0200 > > > Morten Br=F8rup <mb@smartsharesystems.com> wrote: > > > > > > > > From: Mattias R=F6nnblom [mailto:hofors@lysator.liu.se] > > > > > Sent: Sunday, 7 April 2024 11.32 > > > > > > > > > > On 2024-04-04 19:15, Tyler Retzlaff wrote: > > > > > > This series is not intended for merge. It insteat provides exa= mples > > > > > of > > > > > > 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 s= yntax > > > > > > works (unlike on a pointer) and calculation of addresses int= o > > > > > allocated > > > > > > space in ascending order is performed by the compiler instea= d of > > > > > manually. > > > > > > > > > > > > > > > > alloca() is a pretty obscure mechanism, and also not a part of th= e C > > > > > standard. VLAs are C99, and well-known and understood, and very > > > > > efficient. > > > > > > > > The RFC fails to mention why we need to replace VLAs with something= else: > > > > > > > > VLAs are C99, but not C++; VLAs were made optional in C11. > > > > > > > > MSVC doesn't support VLAs, and is not going to: > > > > https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support= - > > arriving-in-msvc/#variable-length-arrays > > > > > > > > > > > > I dislike alloca() too, and the notes section in the alloca(3) man = page > > even discourages the use of alloca(): > > > > https://man7.org/linux/man-pages/man3/alloca.3.html > > > > > > > > But I guess alloca() is the simplest replacement for VLAs. > > > > This RFC patch series opens the discussion for alternatives in diff= erent > > use cases. > > > > > > > > > > The other issue with VLA's is that if the number is something that ca= n be > > externally > > > input, then it can be a source of stack overflow bugs. That is why th= e Linux > > kernel > > > has stopped using them; for security reasons. DPDK has much less of a > > security > > > trust domain. Mostly need to make sure that no data from network is b= eing > > > used to compute VLA size. > > > > > > > Looks like we need to discuss this at the next techboard meeting. > > > > * MSVC doesn't support C11 optional VLAs (and never will). > > * alloca() is an alternative that is available on all platforms/toolcha= in > > combinations. > > * it's reasonable for some VLAs to be turned into regular arrays but it > > would be unsatisfactory to be stuck waiting discussions of defining n= ew > > constant expression macros on a per-use basis. >=20 > We must generally stop using VLAs, for many reasons. > The only available 1:1 replacement is alloca(), so we have to accept that= . >=20 > If anyone still cares about improvements, we can turn alloca()'d arrays i= nto regular arrays after this patch series. >=20 > Alternatives to VLAs are very interesting discussions, but let's not stal= l MSVC progress because of it! Ok, but why we have to rush into 'alloca()' solution if none of us really f= ond of it? As you already noted majority of these cases can be replaced with static si= zed arrays. Let's try to compile a list of what needs to be changed, split it by priori= ties and work progressively through it.=20 Konstantin=20 >=20 > > * there is resistance to using alloca() vs VLA so my proposal is to > > change only the code that is built to target windows. >=20 > I would prefer to get rid of them all, so the CI can build with -Wvla to = prevent them from being introduced again. > Not a strong preference. > On the other hand, the CI's MSVC builds will catch them if used for a Win= dows target. > And limiting to Windows code reduces the amount of work, so that's probab= ly the most realistic solution.