From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 7765EA05DC for ; Sun, 9 Jun 2019 16:24:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 735BF1BD70; Sun, 9 Jun 2019 16:24:05 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 53A101BD4E for ; Sun, 9 Jun 2019 16:24:04 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 6193DBC0071; Sun, 9 Jun 2019 14:24:02 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 9 Jun 2019 15:23:52 +0100 To: Yongseok Koh , , , , , CC: References: <20190603213231.27020-1-yskoh@mellanox.com> From: Andrew Rybchenko Message-ID: <7047a597-ea0d-f159-e95d-0fd8bca5b78d@solarflare.com> Date: Sun, 9 Jun 2019 17:23:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190603213231.27020-1-yskoh@mellanox.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24664.003 X-TM-AS-Result: No-3.976500-8.000000-10 X-TMASE-MatchedRID: oTBA/+sdKabmLzc6AOD8DfHkpkyUphL9OtlHh2+ppE/RLEyE6G4DRA13 bv/YY/bOuiKaHFXVs99PaSCGuTUzHMrA3XqH1SvN020eWoALA9eD33mO/UVvM/yQXCBzKijh3c0 0lAOLPF7Iw09WaLlNqp+IyWoqJXe30x32p7DBxlTfhvTQ/n1nGRfbPFE2GHrVDK0a5ywmRJp0Gh 9AgG9QyDJ4Q8McnaXJHdq74htd0GeXbmjEpvtB854CIKY/Hg3AtOt1ofVlaoLUHQeTVDUrItRnE QCUU+jzjoczmuoPCq1XjApCWvll5/Eb3VBjG3P/nW3qrYvSXEdj6TpigmTdVtmbTSlXjxweb3OK SlAy1vNhwp7J4xhRV/Bi6i4cS/5IGfdqGE9Qpkfi+fTMx9KaNitss6PUa4/cD6GAt+UbooSj1CO 4X0Eqed8x3qzoMNxx X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--3.976500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24664.003 X-MDID: 1560090243-pX-_yodonYZ9 Subject: Re: [dpdk-dev] [RFC 1/3] ethdev: extend flow metadata X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/4/19 12:32 AM, Yongseok Koh wrote: > Currently, metadata can be set on egress path via mbuf tx_meatadata field > with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata. > > This patch extends the usability. > > 1) RTE_FLOW_ACTION_TYPE_SET_META > > When supporting multiple tables, Tx metadata can also be set by a rule and > matched by another rule. This new action allows metadata to be set as a > result of flow match. > > 2) Metadata on ingress > > There's also need to support metadata on packet Rx. Metadata can be set by > SET_META action and matched by META item like Tx. The final value set by > the action will be delivered to application via mbuf metadata field with > PKT_RX_METADATA ol_flag. > > For this purpose, mbuf->tx_metadata is moved as a separate new field and > renamed to 'metadata' to support both Rx and Tx metadata. > > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be > propagated to the other path depending on HW capability. > > Signed-off-by: Yongseok Koh There is a mark on Rx which is delivered to application in hash.fdir.hi. Why do we need one more 32-bit value set by NIC and delivered to application? What is the difference between MARK and META on Rx? When application should use MARK and when META? Is there cases when both could be necessary? Moreover, the third patch adds 32-bit tags which are not delivered to application. May be META/MARK should be simply a kind of TAG (e.g. with index 0 or marked using additional attribute) which is delivered to application? (It is either API breakage (if tx_metadata is removed) or ABI breakage if metadata and tx_metadata will share new location after shinfo). Andrew.