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 92E4B1B57F for ; Tue, 9 Oct 2018 16:53:51 +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-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 13257B00058; Tue, 9 Oct 2018 14:53:50 +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; Tue, 9 Oct 2018 15:53:41 +0100 To: Ferruh Yigit , Dekel Peled , , , , , , , CC: , , Cristian Dumitrescu 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> From: Andrew Rybchenko Message-ID: <6654d2b2-aca4-2202-830a-e6f5853adc48@solarflare.com> Date: Tue, 9 Oct 2018 17:52:59 +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: 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-24144.003 X-TM-AS-Result: No-9.412700-8.000000-10 X-TMASE-MatchedRID: X4bcv0S75KkOwH4pD14DsPHkpkyUphL9wx0jRRxcQfP4JyR+b5tvoLB6 KjveEuzJEzcUmMB6AWeH/4eWCrbvXd7Jizf4VVgF020eWoALA9dr9+Kgn2XgeDtnxw4OiW78R47 F23WRhl5cgiulxglfmgNfBMsVu8GGEUubDEShcPPHt9VUPuskRl3dDPPhjZQS57Oa56Gy3SOWoc vUd65dkaN/+X3jX1W3k4pFeypXwYtVqq6D7545sWg4D2QV/2zL6r3HCixfuKcML9Wb3Qh/hVTNq f3EQ8oxYnP+cq2mFg5XmxqYx7OZlsZXUijhl2l8GQlUVP2iPczHbZsG8T5ZjvnoB3VLBu330lGk ntz0sQH3aCtTBCBhl8Fko3/9LDRTDPIzF4wRfrA5f9Xw/xqKXVkMvWAuahr8wxWsZgByNxZjYGx dKEQ2dMKvTpyHL95dd85CMkJJGJFSzbu77IGXG24XMDwApfRuEIZnDXZmrW7OeN2i52GjB8CV0H I6raD6bztyhy/KPXJ+wPf5YK+rPC8UQzt5OwNBU3PrE77jXyVxpWfdiuWBDi4xsKzFYh1eYOciu 9SAMmeI5zE67yZyQ5n3dB1BpxUEm3pIQOIJ7GinNpUKLkqur0lLd09OvFjP X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.412700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24144.003 X-MDID: 1539096831-KmWApiFEsI2X 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: Tue, 09 Oct 2018 14:53:51 -0000 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 >>