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 5456643FAA;
	Tue,  7 May 2024 02:47:12 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id D12D442E3F;
	Tue,  7 May 2024 02:47:11 +0200 (CEST)
Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com
 [209.85.160.49]) by mails.dpdk.org (Postfix) with ESMTP id 736CA4027B
 for <dev@dpdk.org>; Tue,  7 May 2024 02:47:10 +0200 (CEST)
Received: by mail-oa1-f49.google.com with SMTP id
 586e51a60fabf-23f0d54c5ffso1479098fac.1
 for <dev@dpdk.org>; Mon, 06 May 2024 17:47:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1715042829;
 x=1715647629; 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=TWMiP7DshJIhzfpoMtddqVkvG9pdMu1yiImnoSeHmCE=;
 b=jiKdcO1WtQkOmar2Nki4497DmpPyQPUnTtfr8RXh2uaD5boMJznWMys+8IErAqFAXo
 Tpo5bwZAdTwhsOwzQTbYHfy8rD95Vv6HcDq5ydp8FO35bP2j2ZNKbiaxL8cbC9lneSPr
 mJdQKi+0yMyDzPF/wLGVSN1IN8AESJ+ZsRFMhpQMrg50vVRQwnzXnNv9jLJBBGu2wixn
 MOEYtNLsG4Qzop3vFpDDr163tST7jjE2Q0qJaru0HSmg0kxAZv3tzBnFEkJ2faj5qyrC
 LziireKT8D+klUdxce6ShMn3WiPoeroO4zKDcb3dZdFD8t4uJvnjeLg17u99hVU/dArq
 610g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1715042829; x=1715647629;
 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=TWMiP7DshJIhzfpoMtddqVkvG9pdMu1yiImnoSeHmCE=;
 b=huw/syDe5x8d+FQXPWhM06XAqCu93wGUBo11ospBcjeNntiinBv9c6cUEua6C01Qbv
 z3b8z0QyomG1K252hnUxEBeABIxwAl7lWKe9jfhPrEdQdLNNWOjC4LcAECP06jpmxitq
 fCa9KbJQ8AQHSaXthhyvjHKVzwg2qSjKeA/O4VYD/vzuFmpXscq8wWUxVZUpYf4AigyN
 zSm1y4xlnPkm0cOLjQy/bauXED2qL1NHKLEUPs/ImfjqyzpYKKq94n8PDcHdR8zhw/rU
 xtb3cqNfD4ddE9MTg2iZhijz16fooaCPIYe7yqy+a95ksYIaqPztt/gIrRlyqSuGVb1H
 ysrw==
X-Gm-Message-State: AOJu0YzoKz5d2mDSdUAXvaIb4eQp1ijuPgkEzN1AZGLyzv7vokVuS8B9
 c1CZ3gvtAhnPiUCT+W3i/GWKhg8b/veC94RIjNpd4ob9yJem43zJhqIiGthHKfU=
X-Google-Smtp-Source: AGHT+IGZNMg7Xw4m840L6TM8bIuitkKzdlYlsMF6u22r5MWKbaJcx4w2thjsuIvY1Q6/3gTY8Rx/ow==
X-Received: by 2002:a05:6870:9d06:b0:23d:697:e8fd with SMTP id
 pp6-20020a0568709d0600b0023d0697e8fdmr14623143oab.40.1715042829429; 
 Mon, 06 May 2024 17:47:09 -0700 (PDT)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
 by smtp.gmail.com with ESMTPSA id
 b2-20020a637142000000b005f77b2c207dsm8592139pgn.12.2024.05.06.17.47.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 06 May 2024 17:47:09 -0700 (PDT)
Date: Mon, 6 May 2024 17:47:07 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Tyler Retzlaff <roretzla@linux.microsoft.com>
Cc: dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1cA==?=
 <mb@smartsharesystems.com>, Akhil Goyal <gakhil@marvell.com>, Aman Singh
 <aman.deep.singh@intel.com>, Anatoly Burakov <anatoly.burakov@intel.com>,
 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Bruce Richardson
 <bruce.richardson@intel.com>, Chengwen Feng <fengchengwen@huawei.com>,
 Dariusz Sosnowski <dsosnowski@nvidia.com>, Dmitry Kozlyuk
 <dmitry.kozliuk@gmail.com>, Fan Zhang <fanzhang.oss@gmail.com>, Ferruh
 Yigit <ferruh.yigit@amd.com>, Harman Kalra <hkalra@marvell.com>, Harry van
 Haaren <harry.van.haaren@intel.com>, Honnappa Nagarahalli
 <honnappa.nagarahalli@arm.com>, Jiayu Hu <hujiayu.hu@foxmail.com>, Jingjing
 Wu <jingjing.wu@intel.com>, Kevin Laatz <kevin.laatz@intel.com>, Konstantin
 Ananyev <konstantin.v.ananyev@yandex.ru>, Matan Azrad <matan@nvidia.com>,
 Ori Kam <orika@nvidia.com>, Pallavi Kadam <pallavi.kadam@intel.com>, Reshma
 Pattan <reshma.pattan@intel.com>, Sameh Gobriel <sameh.gobriel@intel.com>,
 Suanming Mou <suanmingm@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>,
 Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Vladimir Medvedkin
 <vladimir.medvedkin@intel.com>, Volodymyr Fialko <vfialko@marvell.com>,
 Yipeng Wang <yipeng1.wang@intel.com>
Subject: Re: [PATCH v3 08/19] gro: remove use of VLAs for Windows built code
Message-ID: <20240506174707.253a4316@hermes.local>
In-Reply-To: <1715019531-22796-9-git-send-email-roretzla@linux.microsoft.com>
References: <1713397319-26135-1-git-send-email-roretzla@linux.microsoft.com>
 <1715019531-22796-1-git-send-email-roretzla@linux.microsoft.com>
 <1715019531-22796-9-git-send-email-roretzla@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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 Mon,  6 May 2024 11:18:40 -0700
Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:

> MSVC does not support VLAs, replace VLAs with standard C arrays
> or alloca(). alloca() is available for all toolchain/platform
> combinations officially supported by DPDK.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/gro/rte_gro.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/gro/rte_gro.c b/lib/gro/rte_gro.c
> index d824eeb..0f9e85c 100644
> --- a/lib/gro/rte_gro.c
> +++ b/lib/gro/rte_gro.c
> @@ -179,7 +179,7 @@ struct gro_ctx {
>  	struct gro_vxlan_udp4_item vxlan_udp_items[RTE_GRO_MAX_BURST_ITEM_NUM]
>  			= {{{0}} };
>  
> -	struct rte_mbuf *unprocess_pkts[nb_pkts];
> +	struct rte_mbuf **unprocess_pkts = alloca(sizeof(struct rte_mbuf *) * nb_pkts);
>  	uint32_t item_num;
>  	int32_t ret;
>  	uint16_t i, unprocess_num = 0, nb_after_gro = nb_pkts;
> @@ -360,7 +360,7 @@ struct gro_ctx {
>  		uint16_t nb_pkts,
>  		void *ctx)
>  {
> -	struct rte_mbuf *unprocess_pkts[nb_pkts];
> +	struct rte_mbuf **unprocess_pkts = alloca(sizeof(struct rte_mbuf *) * nb_pkts);
>  	struct gro_ctx *gro_ctx = ctx;
>  	void *tcp_tbl, *udp_tbl, *vxlan_tcp_tbl, *vxlan_udp_tbl, *tcp6_tbl;
>  	uint64_t current_time;


According to rte_gro.h the maximum supported burst size is

#define RTE_GRO_MAX_BURST_ITEM_NUM 128U
/**< the max number of packets that rte_gro_reassemble_burst()
 
And it looks like the code already truncates at that.