From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70074.outbound.protection.outlook.com [40.107.7.74]) by dpdk.org (Postfix) with ESMTP id 8C6123250 for ; Tue, 28 Aug 2018 21:15:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HLEHq3fHDoLV4LWfYu+G2NkqRP679mt8MEs21Oagoew=; b=K8eiQBVRAYOztxNLdHqqDpOIYIj59WpULKYdiGLQX+ID3VKNjpXHP6WfYHpKWACmz/P1R+KQ5srslxaZBo1hU7Zj2q0ZxiYtELheaFZwttP+Qab33ag0HPIau66s6Y6m12NorIVWtaw5Zgx4I3FMnhzvYYq29wmp0yNXi3tpAeo= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4058.eurprd05.prod.outlook.com (52.134.72.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.14; Tue, 28 Aug 2018 19:15:43 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::d45:8e84:6d63:c57c]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::d45:8e84:6d63:c57c%2]) with mapi id 15.20.1080.015; Tue, 28 Aug 2018 19:15:43 +0000 From: Yongseok Koh To: "Ananyev, Konstantin" CC: Andrew Rybchenko , Dekel Peled , "dev@dpdk.org" , Ori Kam , Shahaf Shuler , Thomas Monjalon , "Yigit, Ferruh" , Adrien Mazarguil , Olivier Matz Thread-Topic: [dpdk-dev] [RFC] ethdev: support metadata as flow rule criteria Thread-Index: AQHUMtniDLi05FljDkeEuymeJMrzdKTL0xcAgAGjNQCAAUmtgIAG4ViA Date: Tue, 28 Aug 2018 19:15:42 +0000 Message-ID: References: <1534146418-1060-1-git-send-email-dekelp@mellanox.com> <4da29594-c4c5-9006-2ecb-4f4094db42a5@solarflare.com> <20180823213138.GB31847@yongseok-MBP.local> <2601191342CEEE43887BDE71AB977258E9FA51C7@IRSMSX102.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258E9FA51C7@IRSMSX102.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [2607:fb90:4afa:9ebd:bd01:1265:52d4:2d3d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4058; 6:F6MKXA7aqIGVbGqAjlUpWFtc6IFaoLgOAm0AiayVGUHHwYhEr8/OGYpjuWYyxR899ZJt5FLdwNlmjFnYJEv22zIcrjvr6J8ai0tjRbEIpHyWENabgzV8OuTvAKkzz1EdkCfns6wz/d0U8SEbTxCe96F4+E1MHJN1pNYfSwkISX8rF8/ECv/EMGSSHYoBTYed4X3dQoXEVXGiVYXXPRv2Jrh+4io2pBoL/l3i1bKwhjnywA9/ef8b+xXGuf9vZT6dFu4ayHe0wHSXxHBpnqr6qmCiTksxRstkvzvZZWwQJ61+1GYM96CP3nOvLZyVxnBN1FvHyijmAWswBY/mrHrYJXvZ3ZctgKNOegCJ6fgEJ9uIp5FkBVeUxiawtNxzeuNvLwI6sX2zDgtOoPdoX9uwtIZPNuALtu6hl/2gl4hst7sy5i47sOjjaujKSNRZp7CN07USRLQrA7aoNypcr+YkwQ==; 5:KXCa8c6rip3g4YkCOy4S0B+7WOjYg7JR6mvcQuhA5/L1jiEshewFbxJupXVUXpaXbsLyRKOAOiQIOIOJUgVG0LnOVEk2Ja1MbYnTA2FE3gMuORrX7cbPSQboxOhsZ2+S5e8BVeTdljReZ/w5UQNuRpw48KL+tcx1X4uct1HiGdY=; 7:gXCp37hrVdUZszCtGBOD0k1e9AVVqd9J8lmfBtDLIv5wgTz55vioKxgRrUYZQfxJSHM3BS3Gds4aylmGD+C7wEHGmaI8kyudFNRFCrs5RvFJMN8FetM7eno5dhisxTTEzE+CYLq8W8Y90AiJjEb29Gu70xxJt8aHORBQgjRkNCM44aSKkkWBrQ9yYH/fdoljhL+B2XErtuDo4yNPMdKbc/XhGfQz2rOUAscT4y033svwX+P+XQX/u4lXm4rGpYCC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c86f1f6a-9a8a-448c-1434-08d60d1aa654 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0502MB4058; x-ms-traffictypediagnostic: DB3PR0502MB4058: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(823301075)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699016); SRVR:DB3PR0502MB4058; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4058; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(346002)(136003)(13464003)(199004)(189003)(8676002)(5660300001)(81156014)(5250100002)(97736004)(316002)(54906003)(76176011)(82746002)(83716003)(99286004)(7736002)(305945005)(6916009)(478600001)(4326008)(81166006)(6246003)(106356001)(105586002)(93886005)(33656002)(25786009)(2900100001)(14454004)(86362001)(229853002)(36756003)(11346002)(53546011)(8936002)(102836004)(256004)(2906002)(6506007)(6116002)(6512007)(486006)(53936002)(2616005)(476003)(446003)(68736007)(6436002)(6486002)(186003)(46003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4058; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ve9asi1+EpWCy+P/4iw5z93gobHI2aWVfr+uouyQX4O9XZxwiadAT3QUwIY2243SDA78n931zKQA18TaF6EKJZ/MXhXzdwRM+Gud9qOezxYMb3z/T53kpyGeTWwLFTX+HkSRd/B68G//sLHAUlXiy9bl84nmKGiFCc7Z5v+GhsIzMUc4CqXG1LW8ma/wX+TSRPNKC32TnNgB6tcGHvphlzKlKoCnFb+7frVSa6pdCqnpPNc0dq5bvGRU+ICsIKRJaAEy3zs9XjKIyL+bu0lKe9UcZNsvE4QmOmZNdB2+eMPWB15lJ/3S7H0af+/m6iV+TpZkveXqIt3Bn4OGVJmMU5o3GKG5OK27Fgs6wovE3WU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <2BCE4C3EDA337042A4AFFD63C66482E3@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: c86f1f6a-9a8a-448c-1434-08d60d1aa654 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2018 19:15:42.8601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4058 Subject: Re: [dpdk-dev] [RFC] 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, 28 Aug 2018 19:15:46 -0000 > On Aug 24, 2018, at 3:11 AM, Ananyev, Konstantin wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Yongseok Koh [mailto:yskoh@mellanox.com] >> Sent: Thursday, August 23, 2018 10:32 PM >> To: Andrew Rybchenko >> Cc: Dekel Peled ; dev@dpdk.org; orika@mellanox.com;= shahafs@mellanox.com; Thomas Monjalon >> ; Ananyev, Konstantin ; Yigit, Ferruh ; Adrien >> Mazarguil ; Olivier Matz >> Subject: Re: [dpdk-dev] [RFC] ethdev: support metadata as flow rule crit= eria >>=20 >> On Wed, Aug 22, 2018 at 04:31:14PM +0300, Andrew Rybchenko wrote: >>> On 13.08.2018 10:46, Dekel Peled wrote: >>>> Current implementation of rte_flow allows match pattern of flow rule, >>>> based on packet data or header fields. >>>> This limits the application use of match patterns. >>>>=20 >>>> For example, consider a vswitch application which controls a set of VM= s, >>>> connected with virtio, in a fabric with overlay of VXLAN. >>>> Several VMs can have the same inner tuple, while the outer tuple is >>>> different and controlled by the vswitch (encap action). >>>> For the vswtich to be able to offload the rule to the NIC, it must use= a >>>> unique match criteria, independent from the inner tuple, to perform th= e >>>> encap action. >>>>=20 >>>> This RFC adds support for additional metadata to use as match pattern. >>>> The metadata is an opaque item, fully controlled by the application. >>>>=20 >>>> The use of metadata is relevant for egress rules only. >>>> It can be set in the flow rule using the RTE_FLOW_ITEM_META. >>>>=20 >>>> Application should set the packet metdata in the mbuf->metadata 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 fl= ow >>>> rules. >>>>=20 >>>> For example, to do an encap action depending on the VM id, the >>>> application needs to configure 'match on metadata' rte_flow rule with >>>> VM id as metadata, along with desired encap action. >>>> When preparing an egress data packet, application will set VM id data = in >>>> mbuf metadata field and set PKT_TX_METADATA flag. >>>>=20 >>>> PMD will send data packets to NIC, with VM id as metadata. >>>> Egress flow on NIC will match metadata as done with other criteria. >>>> Upon match on metadata (VM id) the appropriate encap action will be >>>> performed. >>>>=20 >>>> This RFC 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. >>>> It also enhances struct rte_mbuf with new data item, uint64_t metadata= . >>>>=20 >>>> Comments are welcome. >>>>=20 >>>> Signed-off-by: Dekel Peled >>>> --- >>>> doc/guides/prog_guide/rte_flow.rst | 21 +++++++++++++++++++++ >>>> lib/librte_ethdev/rte_flow.c | 1 + >>>> lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++++ >>>> lib/librte_mbuf/rte_mbuf.h | 11 +++++++++++ >>>> 4 files changed, 58 insertions(+) >>>>=20 >>>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guid= e/rte_flow.rst >>>> index b305a72..b6e35f1 100644 >>>> --- a/doc/guides/prog_guide/rte_flow.rst >>>> +++ b/doc/guides/prog_guide/rte_flow.rst >>>> @@ -1191,6 +1191,27 @@ Normally preceded by any of: >>>> - `Item: ICMP6_ND_NS`_ >>>> - `Item: ICMP6_ND_OPT`_ >>>> +Item: ``META`` >>>> +^^^^^^^^^^^^^^ >>>> + >>>> +Matches an application specific 64 bit metadata item. >>>> + >>>> +- Default ``mask`` matches any 64 bit value. >>>> + >>>> +.. _table_rte_flow_item_meta: >>>> + >>>> +.. table:: META >>>> + >>>> + +----------+----------+---------------------------+ >>>> + | Field | Subfield | Value | >>>> + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+ >>>> + | ``spec`` | ``data`` | 64 bit metadata value | >>>> + +----------+--------------------------------------+ >>>> + | ``last`` | ``data`` | upper range value | >>>> + +----------+----------+---------------------------+ >>>> + | ``mask`` | ``data`` | zeroed to match any value | >>>> + +----------+----------+---------------------------+ >>>> + >>>> Actions >>>> ~~~~~~~ >>>> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow= .c >>>> index cff4b52..54e5ef8 100644 >>>> --- a/lib/librte_ethdev/rte_flow.c >>>> +++ b/lib/librte_ethdev/rte_flow.c >>>> @@ -66,6 +66,7 @@ struct rte_flow_desc_data { >>>> sizeof(struct rte_flow_item_icmp6_nd_opt_sla_eth)), >>>> MK_FLOW_ITEM(ICMP6_ND_OPT_TLA_ETH, >>>> sizeof(struct rte_flow_item_icmp6_nd_opt_tla_eth)), >>>> + MK_FLOW_ITEM(META, sizeof(struct rte_flow_item_meta)), >>>> }; >>>> /** Generate flow_action[] entry. */ >>>> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow= .h >>>> index f8ba71c..b81c816 100644 >>>> --- a/lib/librte_ethdev/rte_flow.h >>>> +++ b/lib/librte_ethdev/rte_flow.h >>>> @@ -413,6 +413,15 @@ enum rte_flow_item_type { >>>> * See struct rte_flow_item_mark. >>>> */ >>>> RTE_FLOW_ITEM_TYPE_MARK, >>>> + >>>> + /** >>>> + * [META] >>>> + * >>>> + * Matches a metadata value specified in mbuf metadata field. >>>> + * >>>> + * See struct rte_flow_item_meta. >>>> + */ >>>> + RTE_FLOW_ITEM_TYPE_META, >>>> }; >>>> /** >>>> @@ -849,6 +858,22 @@ struct rte_flow_item_gre { >>>> #endif >>>> /** >>>> + * RTE_FLOW_ITEM_TYPE_META. >>>> + * >>>> + * Matches a specified metadata value. >>>> + */ >>>> +struct rte_flow_item_meta { >>>> + uint64_t data; >>>> +}; >>>> + >>>> +/** Default mask for RTE_FLOW_ITEM_TYPE_META. */ >>>> +#ifndef __cplusplus >>>> +static const struct rte_flow_item_meta rte_flow_item_meta_mask =3D { >>>> + .data =3D RTE_BE64(UINT64_MAX), >>>> +}; >>>> +#endif >>>> + >>>> +/** >>>> * RTE_FLOW_ITEM_TYPE_FUZZY >>>> * >>>> * Fuzzy pattern match, expect faster than default. >>>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h >>>> index 9ce5d76..8f06a78 100644 >>>> --- a/lib/librte_mbuf/rte_mbuf.h >>>> +++ b/lib/librte_mbuf/rte_mbuf.h >>>> @@ -182,6 +182,11 @@ >>>> /* add new TX flags here */ >>>> /** >>>> + * This flag indicates that the metadata field in the mbuf is in use. >>>> + */ >>>> +#define PKT_TX_METADATA (1ULL << 41) >>>> + >>>> +/** >>>> * UDP Fragmentation Offload flag. This flag is used for enabling UDP >>>> * fragmentation in SW or in HW. When use UFO, mbuf->tso_segsz is use= d >>>> * to store the MSS of UDP fragments. >>>> @@ -593,6 +598,12 @@ struct rte_mbuf { >>>> */ >>>> struct rte_mbuf_ext_shared_info *shinfo; >>>> + /** >>>> + * Application specific metadata value for flow rule match. >>>> + * Valid if PKT_TX_METADATA is set. >>>> + */ >>>> + uint64_t metadata; >>>> + >>>=20 >>> I don't see the difference from hash union which is 64-bit wide as well= . >>> hash.fdir.hi is used by flow mark action and mark match item (but just >>> 32-bit). >>=20 >> Rx metadata would be different from flow mark ID. Mark ID is set when th= e flow >> is created (it is a kind of marking classification result) but metadata = could be >> sent by other entity, e.g. VM-to-VM traffic or VM-to-HV traffic. >=20 > Ok, but it could be either rss OR flow id OR metdata (based on ol_flags) = - > hash is a union after all. > Konstantin Not sure, why can't both (flow ID and metadata) be set in a mbuf? Why do you think it has to be exclusive? Thanks, Yongseok