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 9ADD346036; Thu, 9 Jan 2025 18:27:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 219A340612; Thu, 9 Jan 2025 18:27:15 +0100 (CET) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id 79F7F40430 for ; Thu, 9 Jan 2025 18:27:13 +0100 (CET) Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4YTWsN2f5Cz6L5Ng; Fri, 10 Jan 2025 01:26:00 +0800 (CST) Received: from frapeml500007.china.huawei.com (unknown [7.182.85.172]) by mail.maildlp.com (Postfix) with ESMTPS id 0FB9514038F; Fri, 10 Jan 2025 01:27:12 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500007.china.huawei.com (7.182.85.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 9 Jan 2025 18:27:11 +0100 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.039; Thu, 9 Jan 2025 18:27:11 +0100 From: Konstantin Ananyev To: Andre Muezerie , Konstantin Ananyev , Vladimir Medvedkin CC: "dev@dpdk.org" Subject: RE: [PATCH 1/2] lib/ipsec: compile ipsec on Windows Thread-Topic: [PATCH 1/2] lib/ipsec: compile ipsec on Windows Thread-Index: AQHbYFqL4dVqHwTJkk6cxyHKgfsDErMOshrg Date: Thu, 9 Jan 2025 17:27:11 +0000 Message-ID: <506a31ede96645a299b31445f8574fa2@huawei.com> References: <1736181948-8907-1-git-send-email-andremue@linux.microsoft.com> <1736181948-8907-2-git-send-email-andremue@linux.microsoft.com> In-Reply-To: <1736181948-8907-2-git-send-email-andremue@linux.microsoft.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.33.80] Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > Removed VLA for compatibility with MSVC (which does not support VLAs). > Used alloca when a constant fixed length that can be used instead is > not known. >=20 ... =20 > Signed-off-by: Andre Muezerie > --- ... > diff --git a/lib/ipsec/esp_inb.c b/lib/ipsec/esp_inb.c > index f159bf7460..305ac48dc5 100644 > --- a/lib/ipsec/esp_inb.c > +++ b/lib/ipsec/esp_inb.c > @@ -370,8 +370,9 @@ esp_inb_pkt_prepare(const struct rte_ipsec_session *s= s, struct rte_mbuf *mb[], > struct rte_cryptodev_sym_session *cs; > struct replay_sqn *rsn; > union sym_op_data icv; > - uint32_t dr[num]; > + uint32_t *dr; I understand the intention, but obviously as the lib maintainer, I am no very happy with mechanic replacement of VLAs with alloca() calls. Again, while it helps to make MSVC happy, it doesn't really solve a potenti= al problem with using VLAs here - I we can end-up with stack overflowed if someone wil= l call one of these functions with input arrays of huge size. It would be much better to re-work the internal functions to work over fixe= d-size array an then call them in a loop.=20 The main issue here is that by API convention we need to re-arrange input a= rray by moving bad (not processed) mbuf after the good ones. But even with that splitting processing into multiple iterations over small= chunks might help I think. =20 > + dr =3D alloca(sizeof(uint32_t) * num); > sa =3D ss->sa; > cs =3D ss->crypto.ses; > rsn =3D rsn_acquire(sa); > @@ -576,12 +577,16 @@ tun_process(struct rte_ipsec_sa *sa, struct rte_mbu= f *mb[], > uint32_t sqn[], uint32_t dr[], uint16_t num, uint8_t sqh_len) > { > uint32_t adj, i, k, tl, bytes; > - uint32_t hl[num], to[num]; > - struct rte_esp_tail espt[num]; > - struct rte_mbuf *ml[num]; > + uint32_t *hl, *to; > + struct rte_esp_tail *espt; > + struct rte_mbuf **ml; > const void *outh; > void *inh; >=20 > + hl =3D alloca(sizeof(uint32_t) * num); > + to =3D alloca(sizeof(uint32_t) * num); > + espt =3D alloca(sizeof(struct rte_esp_tail) * num); > + ml =3D alloca(sizeof(struct rte_mbuf *) * num); > /* > * remove icv, esp trailer and high-order > * 32 bits of esn from packet length