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 DA7CEA0548 for ; Mon, 26 Apr 2021 09:54:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B79A141188; Mon, 26 Apr 2021 09:54:44 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id BC60F41188; Mon, 26 Apr 2021 09:54:42 +0200 (CEST) IronPort-SDR: nnA4pvY1ogV0AvsK+bIrCZf2cK+UVw2fi2Dh7pr+A31vz+cAUYXo+Qn5/qI4qHjWwb/og/r53X giawh1YVKqAg== X-IronPort-AV: E=McAfee;i="6200,9189,9965"; a="195849401" X-IronPort-AV: E=Sophos;i="5.82,251,1613462400"; d="scan'208";a="195849401" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 00:54:41 -0700 IronPort-SDR: dTiBquSSVdXpsYy7xa1kJI2cG8I5WvHHZ4Fam8DthZGSZAsVEBeXEWZNdWEFb3+BWcHUWUrH50 xI8XkUBk7YCg== X-IronPort-AV: E=Sophos;i="5.82,251,1613462400"; d="scan'208";a="429301320" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.240.23]) ([10.213.240.23]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 00:54:37 -0700 To: Thomas Monjalon , Gregory Etelson , "dev@dpdk.org" Cc: Matan Azrad , Raslan Darawsheh , "stable@dpdk.org" , Viacheslav Ovsiienko , Shahaf Shuler , Asaf Penso References: <20210419130204.24348-1-getelson@nvidia.com> <20210425155722.32477-1-getelson@nvidia.com> <43215430-8e29-4869-8d69-6c385e612153@www.fastmail.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Mon, 26 Apr 2021 08:54:34 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2 1/2] 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 4/25/2021 6:07 PM, Thomas Monjalon wrote: > Dim 25 avr 2021, à 19:01, Gregory Etelson a écrit : >> Hello Thomas, >> >>> Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit : >>>> Tunnel offload API requires application to query PMD for specific flow >>>> items and actions. Application uses these PMD specific elements to >>>> build flow rules according to the tunnel offload model. >>>> The model does not restrict private elements location in a flow rule, >>>> but the current MLX5 PMD implementation expects that tunnel offload >>>> rule will begin with PMD specific elements. >>>> The patch removes that placement limitation in MLX5 PMD. >>>> >>>> Cc: stable@dpdk.org >>>> >>>> Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload") >>> >>> Cc: stable must be just after the Fixes line. >>> >>> There is a testpmd patch in the same series, is it OK to be merged in mlx >>> tree? >> >> The tunnel offload model can be complicated. >> The testpmd patch that comes with this one emphasizes how application >> can construct a flow rule without placement restrictions. >> I think that both patches should be merged. > > That's not the question. > One patch should be merged in mlx tree, while the other one should target next-net. > In such a situation, quite often we split in different series. > For this case, it's up to Raslan and Ferruh to agree on how to proceed. > I am OK to get both to next-net, as long as driver patch is Ack'ed. It seems there is a relation between driver and testpmd patch, but I am trying to figure out how tightly they are coupled, which may be sign of something wrong.