From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F0141A00C4; Thu, 31 Oct 2019 10:01:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4F4B21C1F5; Thu, 31 Oct 2019 10:01:46 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 0AB8B1C11B for ; Thu, 31 Oct 2019 10:01:45 +0100 (CET) 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-us5.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 89F3B4C0059; Thu, 31 Oct 2019 09:01:43 +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; Thu, 31 Oct 2019 09:01:35 +0000 To: Viacheslav Ovsiienko , CC: , , , , References: <1572377502-13620-1-git-send-email-viacheslavo@mellanox.com> <1572455548-23420-1-git-send-email-viacheslavo@mellanox.com> <1572455548-23420-3-git-send-email-viacheslavo@mellanox.com> From: Andrew Rybchenko Message-ID: <4964cedf-22cf-deee-79f4-e1ae002c1392@solarflare.com> Date: Thu, 31 Oct 2019 12:01:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1572455548-23420-3-git-send-email-viacheslavo@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-25012.003 X-TM-AS-Result: No-6.585600-8.000000-10 X-TMASE-MatchedRID: 1GZI+iG+MtfmLzc6AOD8DfHkpkyUphL9I5rZlsanIIWztEJA/aevveWU N1Ca5NeJ2OpekNHHMko3LVkm9UV6zBQRASVzWG92fY+iJfFQBxdKgIbix5+XxExr7YP74w0XVQU 8VbWsRfhxmcXeaKpVfujOMDIctEiB5a3ROJ4+8LpNkpJuEXQygWv34qCfZeB4/IA9L2ORlaIHLJ WKaOYkk/cjgXGfMR6z4E/CNSLlCp+9vdftp9VHIjdfT4zyWoZSPqNie8gbBOtUjspoiX02FyoZX FJfmWg7jEQhutXfidloFgfZP2Kdx9TFyyH6K17fZ93oz43dfXF9LQinZ4QefL6qvLNjDYTwsuf7 RWbvUtx1r8FBbF0I5gtuKBGekqUpIG4YlbCDECtfW6meCfUbJwVKfv15RJhiRpE+uNm52CvqoaZ 72RFWcPzX0VFCAZhdNdfLEvP9Stwq3ddFKfqvXufdn8xP2xOjnh8XuCtjuHLcgW38hskAmqKAQf LsnhLrKWSt4DmvbhpicKLmK2TeKmsPn5C6nWpTnqg/VrSZEiM= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--6.585600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25012.003 X-MDID: 1572512504-k91YtRUN5COa Subject: Re: [dpdk-dev] [PATCH v6 2/2] ethdev: move egress metadata to dynamic field 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 10/30/19 8:12 PM, Viacheslav Ovsiienko wrote: > The dynamic mbuf fields were introduced by [1]. The egress metadata is > good candidate to be move from statically allocated field tx_metadata to > dynamic one. Because mbufs are used in half-duplex fashion only, it is > safe to share this dynamic field with ingress metadata. > > The shared dynamic field contains either egress (if application going to > transmit mbuf with tx_burst) or ingress (if mbuf is received with rx_burst) > metadata and can be accessed by RTE_FLOW_DYNF_METADATA() macro or with > rte_flow_dynf_metadata_set() and rte_flow_dynf_metadata_get() helper > routines. PKT_TX_DYNF_METADATA/PKT_RX_DYNF_METADATA flag will be set > along with the data. > > The mbuf dynamic field must be registered by calling > rte_flow_dynf_metadata_register() prior accessing the data. > > The availability of dynamic mbuf metadata field can be checked with > rte_flow_dynf_metadata_avail() routine. > > [1] http://patches.dpdk.org/patch/62040/ > > Signed-off-by: Viacheslav Ovsiienko LGTM I think release notes should be updated. What I don't understand now is the way for application to understand if Tx metadata is supported or not. Corresponding offload flag is removed. I guess the answer is rte_flow_validate() with a rule on egress which tries to match meta and do something (?). It should be highlighted in the documentation in any case, but I'd consider to keep the offload.