From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id B60A5A04B5;
	Thu, 29 Oct 2020 13:58:03 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 0F56DCDD6;
	Thu, 29 Oct 2020 13:54:31 +0100 (CET)
Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113])
 by dpdk.org (Postfix) with ESMTP id 91523CDF9
 for <dev@dpdk.org>; Thu, 29 Oct 2020 13:54:27 +0100 (CET)
Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 021747F476;
 Thu, 29 Oct 2020 15:54:26 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 021747F476
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru;
 s=default; t=1603976066;
 bh=QJ2V2mxD1I+5uLHBlP6KzIyw6J0iD1VsuGRg17HOtfU=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To;
 b=IPaKncBxstM+1VZz4Cr9s0DabsXjJf2VAJHiLwQhdiWvrScF3yCVN7I3YzCRuBFRE
 ZpqTKFITlog3rX0d8rhOkytySkumxQ68tupYBB/I6EJrHLY3GZQiiV/RcVFcM4CJ60
 sFd+bAkspOU/wZ2HE4s9X8ND2BkdMI8AmPvepf80=
To: Ferruh Yigit <ferruh.yigit@intel.com>,
 Ivan Malov <ivan.malov@oktetlabs.ru>, dev@dpdk.org
Cc: Ori Kam <orika@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>,
 Andrey Vesnovaty <andreyv@nvidia.com>
References: <20201029114644.22169-1-ivan.malov@oktetlabs.ru>
 <63125005-f38d-6c7f-f39c-43093085b742@intel.com>
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Organization: OKTET Labs
Message-ID: <5d184de6-b2c7-e8de-f2f2-a1c3276bfe2b@oktetlabs.ru>
Date: Thu, 29 Oct 2020 15:54:25 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <63125005-f38d-6c7f-f39c-43093085b742@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
 shared action conf
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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 10/29/20 3:37 PM, Ferruh Yigit wrote:
> On 10/29/2020 11:46 AM, Ivan Malov wrote:
>> In a flow rule, attribute "transfer" means operation level
>> at which both traffic is matched and actions are conducted.
>>
>> Add the very same attribute to shared action configuration.
>> If a driver needs to prepare HW resources in two different
>> ways, depending on the operation level, in order to set up
>> an action, then this new attribute will indicate the level.
>> Also, when handling a flow rule insertion, the driver will
>> be able to turn down a shared action if its level is unfit.
>>
>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> 
> Hi Ivan,
> 
> Is this for 21.02?

Since the feature is new and experimental, we'd prefer
to see in 20.11 (could be considered as a fix?), but
I realize that it is late and past API freeze.
I'd let net/mlx5 maintainers to decide as the only
driver which supports shared actions now.