From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id A08E91B1C1 for ; Fri, 5 Oct 2018 15:40:48 +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-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 38C136C0090; Fri, 5 Oct 2018 13:40:47 +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; Fri, 5 Oct 2018 14:40:39 +0100 To: Ferruh Yigit , Dekel Peled , , , , , , , CC: , References: <1537108670-11380-1-git-send-email-dekelp@mellanox.com> <1538056677-33846-2-git-send-email-dekelp@mellanox.com> <0d34ba46-336c-6853-55d3-19b8f46d2db9@intel.com> From: Andrew Rybchenko Message-ID: <3f173f88-3206-911c-4330-57a84201a71b@solarflare.com> Date: Fri, 5 Oct 2018 16:39:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <0d34ba46-336c-6853-55d3-19b8f46d2db9@intel.com> 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-24136.003 X-TM-AS-Result: No-9.840000-8.000000-10 X-TMASE-MatchedRID: 6otD/cJAac0OwH4pD14DsPHkpkyUphL9wx0jRRxcQfP4JyR+b5tvoLB6 KjveEuzJEzcUmMB6AWeH/4eWCrbvXd7Jizf4VVgF020eWoALA9dr9+Kgn2XgeDtnxw4OiW78R47 F23WRhl5cgiulxglfmgNfBMsVu8GGEUubDEShcPPHt9VUPuskRhOIBcTrW5K5B4sIhfTjqIFKsl M7VUaEwXb4Bm7FqQnLz1+7FJCqpLLIDWKFjjZHby+PrAd8gbHJCFEIkVv1y6x5UICQcvBF4/gW4 8LNyEdg6JzUl/+Ir1EOjb0PL1TpnN9faxl/I4mhSetBUNZULwB9LQinZ4QefL6qvLNjDYTwsuf7 RWbvUtwEROhiiqtv8lgXepbcl7r7nGRqP2fnZcs8rnaxBrCHkAzvicHfgOhPitzV7qObdMo7UCx S/bq6wdaly2nkus6uh2wYxVtCxtIxhT/NPpftpZNaBz3Xa+yEsIHd+/ejH5dgv6rUiDLgmAyNL7 FetglaJ5h94HIoeZRr+wsK8DJRNrQisFQPfmoc+crICkOzqvho8XToPf/MOR6KOj2ARplb X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.840000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24136.003 X-MDID: 1538746848-F4xEYYhNZAFf Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 1/3] ethdev: support metadata as flow rule criteria 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: , X-List-Received-Date: Fri, 05 Oct 2018 13:40:48 -0000 On 10/5/18 4:31 PM, Ferruh Yigit wrote: > On 9/27/2018 2:57 PM, Dekel Peled wrote: >> As described in [1], a new rte_flow item is added to support metadata >> to use as flow rule match pattern. >> The metadata is an opaque item, fully controlled by the application. >> >> The use of metadata is relevant for egress rules only. >> It can be set in the flow rule using the RTE_FLOW_ITEM_META. >> >> In order to avoid change in mbuf API, exisitng field buf.hash.fdir.hi >> is used to carry the metadata item. This field is used only in >> ingress packets, so using it for egress metadata will not cause >> conflicts. >> >> Application should set the packet metadata in the mbuf dedicated field, >> and set the PKT_TX_METADATA flag in the mbuf->ol_flags. >> The NIC will use the packet metadata as match criteria for relevant >> flow rules. >> >> This patch introduces metadata item type for rte_flow RTE_FLOW_ITEM_META, >> along with corresponding struct rte_flow_item_meta and ol_flag >> PKT_TX_METADATA. >> >> [1] "[RFC,v2] ethdev: support metadata as flow rule criteria" >> http://mails.dpdk.org/archives/dev/2018-August/110194.html >> >> Signed-off-by: Dekel Peled > <...> > >> @@ -526,6 +532,12 @@ struct rte_mbuf { >> uint32_t hi; >> /**< First 4 flexible bytes or FD ID, dependent on >> PKT_RX_FDIR_* flag in ol_flags. */ >> + /** >> + * Above member has optional use on egress: >> + * Application specific metadata value >> + * for flow rule match. >> + * Valid if PKT_TX_METADATA is set. >> + */ >> } fdir; /**< Filter identifier if FDIR enabled */ > Any objection/comment to use hash.fdir.hi for this new "metadata" meaning? Olivier? As for me, I'd prefer to see dedicated union member something like it was suggested in [1]. Andrew. [1] http://mails.dpdk.org/archives/dev/2018-September/111954.html