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 6DC0C43E32; Wed, 10 Apr 2024 11:58:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E3BC9402C7; Wed, 10 Apr 2024 11:58:36 +0200 (CEST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id 39319402C5; Wed, 10 Apr 2024 11:58:36 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VDysg2mV9z6JB2L; Wed, 10 Apr 2024 17:56:55 +0800 (CST) Received: from frapeml100007.china.huawei.com (unknown [7.182.85.133]) by mail.maildlp.com (Postfix) with ESMTPS id E4CEE1400CA; Wed, 10 Apr 2024 17:58:34 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100007.china.huawei.com (7.182.85.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 10 Apr 2024 11:58:34 +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; Wed, 10 Apr 2024 11:58:34 +0200 From: Konstantin Ananyev <konstantin.ananyev@huawei.com> To: Tyler Retzlaff <roretzla@linux.microsoft.com> CC: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>, "Stephen Hemminger" <stephen@networkplumber.org>, "techboard@dpdk.org" <techboard@dpdk.org>, =?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+AgAAHW4CAATbNUIAATwMAgAFTrpA= Date: Wed, 10 Apr 2024 09:58:34 +0000 Message-ID: <e5d4ef87532b48059acb685205c88631@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> <09aac29da90a499ebfc16493e9942bf6@huawei.com> <20240409150834.GA30471@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> In-Reply-To: <20240409150834.GA30471@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.149.235] 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= examples > > > > > > > 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 poin= ters to > > > > > > > > dynamically allocated space. this means multiple subscri= pt syntax > > > > > > > > works (unlike on a pointer) and calculation of addresses= into > > > > > > > allocated > > > > > > > > space in ascending order is performed by the compiler in= stead of > > > > > > > manually. > > > > > > > > > > > > > > > > > > > > > > alloca() is a pretty obscure mechanism, and also not a part o= f the C > > > > > > > standard. VLAs are C99, and well-known and understood, and ve= ry > > > > > > > efficient. > > > > > > > > > > > > The RFC fails to mention why we need to replace VLAs with somet= hing 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-sup= port- > > > > 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 = different > > > > use cases. > > > > > > > > > > > > > > > > The other issue with VLA's is that if the number is something tha= t can be > > > > externally > > > > > input, then it can be a source of stack overflow bugs. That is wh= y the 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 being > > > > > 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/too= lchain > > > > combinations. > > > > * it's reasonable for some VLAs to be turned into regular arrays bu= t it > > > > would be unsatisfactory to be stuck waiting discussions of defini= ng new > > > > constant expression macros on a per-use basis. > > > > > > We must generally stop using VLAs, for many reasons. > > > The only available 1:1 replacement is alloca(), so we have to accept = that. > > > > > > If anyone still cares about improvements, we can turn alloca()'d arra= ys into regular arrays after this patch series. > > > > > > Alternatives to VLAs are very interesting discussions, but let's not = stall MSVC progress because of it! > > > > Ok, but why we have to rush into 'alloca()' solution if none of us real= ly fond of it? >=20 > for the trivial case it is no worse than a VLA. while it isn't > standardized it is available for all platform/toolchains unlike VLA. > most of the code needed to be changed for windows falls into the trivial > case when converted. Personally, I think VLA is much more convenient then alloca(). At least you can do sizeof(vla_array) without a problem. >=20 > there do appear to be cases where VLAs have just been unintentional. > i previously linked a patch where i fixed a case where they were > instantiated inside a cast and there are other cases i'm aware of in the > mlx5 driver where i believe they are unintended. at least with alloca > it is obvious but with a VLA if the expression used to determine the > size is wrapped up in something non-trivial and the author doesn't check > that it is truly a constant expression you get one by surprise. >=20 > > As you already noted majority of these cases can be replaced with stati= c sized arrays. >=20 > unfortunately i don't think this is the case if we are talking about the > entire source tree. Ok, probably I misunderstood this RFC intention: My first thought that it was all you need to make some minimalistic DPDK bu= ild with MSVC. If that's not the case, then what would be the full list of changes that ar= e necessary?=20 =20 > > Let's try to compile a list of what needs to be changed, split it by pr= iorities and work > > progressively through it. >=20 > i agree that working progressively is the way forward, my suggestion > partitioning has been to submit a smaller series that unblocks windows > using alloca as a starting point. this represents only a fraction of the > uses but can also serve for evaluation purposes. My concern here is that we are replacing something that is probably not ide= al with something that is even worse. I do understand that it supposed to be a temporary measure, but as you said alloca() is supported nearly everywhere, so in theory there would be no str= ong reason for maintainers to spend their time on further code rearrangements t= o replace alloca() with static arrays. =20 >=20 > if maintainers can identify a reasonable conversion to static array for > any of the converted instances i can incorporate the prescribed changes. Ok, that's why I suggested to start with the list of required changes. And then decide on component-by-component basis. >From my side, I am ok to spend some time on the libs I am responsible for, to do such code changes. > i would also suggest that in parallel we might introduce a series that > enables -Wvla but suppresses warning about -Wvla at the sites of use. > the purpose of this suggestion is to stop new introductions but also > annotate the uses we would like maintainers to evaluate. perhaps some > could also be trivially eliminated with the series. >=20 > > Konstantin > > > > > > > > > * there is resistance to using alloca() vs VLA so my proposal is to > > > > change only the code that is built to target windows. > > > > > > 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= Windows target. > > > And limiting to Windows code reduces the amount of work, so that's pr= obably the most realistic solution.