From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Rybchenko Subject: Re: [PATCH v3 1/3] ethdev: support metadata as flow rule criteria Date: Tue, 9 Oct 2018 17:52:59 +0300 Message-ID: <6654d2b2-aca4-2202-830a-e6f5853adc48@solarflare.com> 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> <3f173f88-3206-911c-4330-57a84201a71b@solarflare.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , Cristian Dumitrescu To: Ferruh Yigit , Dekel Peled , , , , , , , 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 92E4B1B57F for ; Tue, 9 Oct 2018 16:53:51 +0200 (CEST) In-Reply-To: Content-Language: en-GB 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/9/18 5:46 PM, Ferruh Yigit wrote: > On 10/5/2018 2:39 PM, Andrew Rybchenko wrote: >> 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]. > Another comment, it was from Cristian while discussing something else, since > this field is for egress, shouldn't it be somewhere in second cache line > allocated for Tx? Tx writes to the first cache-line as well, so I see no problem in using hash union for Tx. I think it is better to keep remaining space on the second cache-line for the future use. >> Andrew. >> >> [1] http://mails.dpdk.org/archives/dev/2018-September/111954.html >>