From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <arybchenko@solarflare.com>
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 <dev@dpdk.org>; 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 <ferruh.yigit@intel.com>, Dekel Peled <dekelp@mellanox.com>,
<wenzhuo.lu@intel.com>, <jingjing.wu@intel.com>,
<bernard.iremonger@intel.com>, <dev@dpdk.org>, <olivier.matz@6wind.com>,
<adrien.mazarguil@6wind.com>, <thomas@monjalon.net>
CC: <shahafs@mellanox.com>, <orika@mellanox.com>, Cristian Dumitrescu
<cristian.dumitrescu@intel.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>
<a5411bfa-9d5f-1e11-645a-c35dd4053260@intel.com>
From: Andrew Rybchenko <arybchenko@solarflare.com>
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: <a5411bfa-9d5f-1e11-645a-c35dd4053260@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-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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <dekelp@mellanox.com>
>>> <...>
>>>
>>>> @@ -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
>>