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 C80B1A0032;
	Fri,  1 Oct 2021 11:41:50 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 576044067A;
	Fri,  1 Oct 2021 11:41:50 +0200 (CEST)
Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113])
 by mails.dpdk.org (Postfix) with ESMTP id EB71740040
 for <dev@dpdk.org>; Fri,  1 Oct 2021 11:41:48 +0200 (CEST)
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 65C267F408;
 Fri,  1 Oct 2021 12:41:48 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 65C267F408
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru;
 s=default; t=1633081308;
 bh=HsBPc0yi5q521POO2iwKF/AWRZPaXIqWXKEGwlv+IJc=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To;
 b=ixl7a40KT0OTwXcO55JE+71Pfh3TKIJncxsflqOiGt5jjyKR66DKx2mD/+RFJq7FD
 c/C8tVx13/KBNcEQBMpOXjl2GrplRk9f6VvQ+9qFj3oiBFjRz1EyeJIQQRH/3jKm6w
 j6Qw0Zfx7Lp6Eb1vFKeimE5v2XCfw59b5hTEJ6Pg=
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Ivan Malov <Ivan.Malov@oktetlabs.ru>, dev@dpdk.org,
 Andy Moreton <amoreton@xilinx.com>, orika@nvidia.com,
 ferruh.yigit@intel.com, olivier.matz@6wind.com
References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru>
 <5427719.I9DohtKF8S@thomas>
 <8e1ef3a6-ccf3-abf7-4862-5e6eee9c476d@oktetlabs.ru>
 <2897751.qA9HOvHBi1@thomas>
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Organization: OKTET Labs
Message-ID: <623e0efa-4e66-1823-3ed1-2b804c8b166f@oktetlabs.ru>
Date: Fri, 1 Oct 2021 12:41:48 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <2897751.qA9HOvHBi1@thomas>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v3 0/5] A means to negotiate delivery of Rx
 meta data
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 10/1/21 12:32 PM, Thomas Monjalon wrote:
> 01/10/2021 10:54, Andrew Rybchenko:
>>>> Thomas, if I'm not mistaken, net/mlx5 dv_xmeta_en driver option
>>>> is vendor-specific way to address the same problem.
>>>
>>> Not exactly, it is configuring the capabilities:
>>>   +------+-----------+-----------+-------------+-------------+
>>>   | Mode | ``MARK``  | ``META``  | ``META`` Tx | FDB/Through |
>>>   +======+===========+===========+=============+=============+
>>>   | 0    | 24 bits   | 32 bits   | 32 bits     | no          |
>>>   +------+-----------+-----------+-------------+-------------+
>>>   | 1    | 24 bits   | vary 0-32 | 32 bits     | yes         |
>>>   +------+-----------+-----------+-------------+-------------+
>>>   | 2    | vary 0-24 | 32 bits   | 32 bits     | yes         |
>>>   +------+-----------+-----------+-------------+-------------+
>>
>> Sorry, but I don't understand the difference. Negotiate is
>> exactly about capabilities which we want to use.
> 
> The difference is that dv_xmeta_en is not enabling/disabling
> the delivery of mark/meta.
> It is just extending the scope (cross-domain) and the size.

Enabling/disabling delivery of some bits...

> I think this is not covered in your proposal.

Yes, that's true, since it is too specific this way,
but our proposal can help to make the best automatic
choice from above options depending on negotiation
request.

Of course, you can always enforce via the driver option
and reply on negotiate requests in accordance with
enforced configuration.