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 53D3AA0548;
Mon, 26 Apr 2021 09:54:45 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id DCDB441198;
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 <thomas@monjalon.net>,
Gregory Etelson <getelson@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Matan Azrad <matan@nvidia.com>, Raslan Darawsheh <rasland@nvidia.com>,
"stable@dpdk.org" <stable@dpdk.org>,
Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
Shahaf Shuler <shahafs@nvidia.com>, Asaf Penso <asafp@nvidia.com>
References: <20210419130204.24348-1-getelson@nvidia.com>
<20210425155722.32477-1-getelson@nvidia.com>
<43215430-8e29-4869-8d69-6c385e612153@www.fastmail.com>
<BY5PR12MB4834D5D7230D14508F849616A5439@BY5PR12MB4834.namprd12.prod.outlook.com>
<a0250976-6706-4364-b6c5-543b0486f6c4@www.fastmail.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
X-User: ferruhy
Message-ID: <e77a2875-9285-080a-e23c-60ba6d2d5103@intel.com>
Date: Mon, 26 Apr 2021 08:54:34 +0100
MIME-Version: 1.0
In-Reply-To: <a0250976-6706-4364-b6c5-543b0486f6c4@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/mlx5: fix tunnel offload private
items location
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
Sender: "dev" <dev-bounces@dpdk.org>
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.