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 57FAC41EB2; Thu, 16 Mar 2023 18:26:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F39B40DF6; Thu, 16 Mar 2023 18:26:33 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 7386240DDC; Thu, 16 Mar 2023 18:26:32 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0E7075C00DD; Thu, 16 Mar 2023 13:26:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 16 Mar 2023 13:26:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1678987592; x=1679073992; bh=dzLVsfEIrcacOmWbObAhCcGv2kuxd8+BoLB fCldabwg=; b=a/a7jsdVvNq8jhf6f7PsErjBj4V9E+3jAWjKBXZrbyrnGiEroF1 mMfFXONAVHRBCzk6oog10/FkIgIvFJuJP56bHxS4igLLLeuuUz8HkM2IJ1lM4UZO ngsOaCO9+LS/Ab9+eoTS+odqmLacGIQwi/SWDy2G0m5pNVn2nRKbaRe7keqlHQFW TT3ckQz9/q2CdwUNE2y9C2ymsDaudHcsMhddxLfarvsfLc+8SOTJwJYnCB2QSwXn 7uyQK+2hFHYBP/x1+SgXi5+bCnrWtSmoK0Dp3qdN073IwRwcdgVr2HQJCUhQd6MM xMFeo0b+1+6NSLyECWAbLMonml7GyAWeaMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1678987592; x=1679073992; bh=dzLVsfEIrcacOmWbObAhCcGv2kuxd8+BoLB fCldabwg=; b=l9Am122p1gdQIJ+kuXRHbkmEjAJupei0ZkoKh5ySQthg/cW67Eb BLQglR9xCkhv6MUYp0bIILawU7XnmKV+GdPGWuXskdWvGgUZfJa5EJkV+yLiLWAn Ec0aefRkRAr06Pqg2h43JTBXY0vMejRaAZzkKcVkX41doosKrOBnpDdtbNlljZ4d Gw7eVMLZXqsEbaREKiiQ8teGmVxC5xzDIVVW8Rhmn5UrGPWB0EIyMjBPKh/gVhuW 6WdGVp/+GgvV7AEgVUSOpdtPQeS1T09tzAnvGTjqctpfszK1z//6HCGOTvm6Yzva 95XQgBlVtmApU6VJh+77GK+Lo2Hbh2N9XkA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeftddguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 16 Mar 2023 13:26:30 -0400 (EDT) From: Thomas Monjalon To: Michael Baum Cc: dev@dpdk.org, Aman Singh , Yuying Zhang , Ferruh Yigit , orika@nvidia.com, stable@dpdk.org, olivier.matz@6wind.com Subject: Re: [PATCH] app/testpmd: fix wrong encap/decap size calculation Date: Thu, 16 Mar 2023 18:26:29 +0100 Message-ID: <3407226.QJadu78ljV@thomas> In-Reply-To: <20230316171654.1827514-1-michaelba@nvidia.com> References: <20230316171654.1827514-1-michaelba@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 16/03/2023 18:16, Michael Baum: > Testpmd app has some functions to create either encap or decap buffer > for some special cases: > - "l2_encap" and "l2_decap" > - "mplsogre_encap" and "mplsogre_decap" > - "mplsoudp_encap" and "mplsoudp_decap" > > The functions use both "rte_flow_item_eth" and "rte_flow_item_vlan" > structures to represent the headers and copy them into "raw_encap" > action. The size of either "raw_encap" or "raw_decap" is capculated as capculated -> calculated > sum of headers size. > > However, the both "rte_flow_item_eth" and "rte_flow_item_vlan" contain > more fields than original headers, so using them cause bad size > calculation. > > This patch uses "RTE_ETHER_HDR_LEN" and "RTE_VLAN_HLEN" macros in size > calculation. Honestly I don't know why we have these *_LEN macros in DPDK. We would have the same result with the (more explicit) sizeof(struct rte_ether_hdr) or sizeof(struct rte_vlan_hdr).