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 3ACAFA0A02 for ; Wed, 5 May 2021 19:45:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2ABA8410EB; Wed, 5 May 2021 19:45:38 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id EE9534003C; Wed, 5 May 2021 19:45:34 +0200 (CEST) IronPort-SDR: xHjAklopK3H273g46NBgWePa5ZhI0AY/XmaUTZCTldp1Uii1Vo59L8WiAi9px6Jn3us/cW0InO 4ky0QxohFL7w== X-IronPort-AV: E=McAfee;i="6200,9189,9975"; a="178495846" X-IronPort-AV: E=Sophos;i="5.82,276,1613462400"; d="scan'208";a="178495846" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 May 2021 10:45:33 -0700 IronPort-SDR: N5HSWVGVQpuMGurnyb6r+kX8m58kJ4jQ3PoLpXO2wGO9OcQ7J7WkdDhgaeWZFmQFo7xuKmxhR3 J+VwouZ+QNRA== X-IronPort-AV: E=Sophos;i="5.82,276,1613462400"; d="scan'208";a="433935216" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.194.51]) ([10.213.194.51]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 May 2021 10:45:31 -0700 To: Gregory Etelson , "dev@dpdk.org" Cc: Matan Azrad , Ori Kam , Raslan Darawsheh , "stable@dpdk.org" , Slava Ovsiienko , Shahaf Shuler References: <20210419130204.24348-1-getelson@nvidia.com> <20210502080817.17737-1-getelson@nvidia.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <303e2815-ac2f-36df-1867-bf398be0306c@intel.com> Date: Wed, 5 May 2021 18:45:27 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] net/mlx5: fix tunnel offload private items location X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 5/4/2021 10:12 AM, Gregory Etelson wrote: > Hello Ferruh, > > [:snip:] > >> Hi Gregory, >> >> The were some questions around testpmd part of this patch in previous >> version, they are not answered and this version is dropping the testpmd >> part. >> > > The tunnel offload API allows application to place tunnel offload elements at any valid location in a flow rule. How PMD should detect the tunnel offload elements? And which API are we talking about, is there enough documentation in the API about the location of the tunnel offload elements, or should we clarify it more? > Current testpmd code places tunnel offload items > at the beginning of pattern array and tunnel offload actions at the beginning of actions array. Got it, so this patch is removing false expectation (about the location of the tunnel offload elements in flow rule) in the PMD, right? As far as I understand testpmd already satisfies this false expectation, so the problem should not be visible with testpmd. Was there a visible user impact, like any application failing because of this false expectation, or is this theoretical fix to be correct with API contract? btw, I can see 'MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL' still checked if it in the first location of the items (items[0].type), in 'flow_dv_validate()', 'mlx5_flow_dv.c' https://git.dpdk.org/dpdk/tree/drivers/net/mlx5/mlx5_flow_dv.c?h=v21.05-rc1#n6298 Can you please confirm that this is expected? > The testpmd patch in v1 & v2 changed location of tunnel offload elements in a flow rule. > >> Is it safe to remove the testpmd part? If so why was the changes for at first >> place? >> > > That patch was not a fix - it emphasized general usage of the tunnel offload API. > Current testpmd code works fine. > >> And can you please reply to the questions on the testpmd patch for the >> record? >> > > I'll add my replies. > >> Thanks, >> Ferruh > > Regards, > Gregory >