From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50062.outbound.protection.outlook.com [40.107.5.62]) by dpdk.org (Postfix) with ESMTP id 06D685A for ; Wed, 29 Aug 2018 08:33:21 +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=G0CkyhXvhK+SzbLsy9niQpt1SuRY8BbSOHnomwBLu9M=; b=fXGEs7swwlV04G5EzrrWF4AgRKHHsUm84KRimQh5/D758D27zH99vcN8LKkzEBcGAyw7d4FHRNBwWYV0JpNy0KhnIL3Q4GgzRV8BJe4xvP+GX/J6wJ//YMNNU6P1G44iFyfFEfn+j9bfDfFSXpY1NVtQB0GyXTm1NjmaRyskNVs= Received: from VI1PR05MB4224.eurprd05.prod.outlook.com (52.133.12.13) by VI1SPR8PMB101.eurprd05.prod.outlook.com (10.163.248.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.13; Wed, 29 Aug 2018 06:33:19 +0000 Received: from VI1PR05MB4224.eurprd05.prod.outlook.com ([fe80::4934:cd8f:bfc8:d6a8]) by VI1PR05MB4224.eurprd05.prod.outlook.com ([fe80::4934:cd8f:bfc8:d6a8%4]) with mapi id 15.20.1080.015; Wed, 29 Aug 2018 06:33:19 +0000 From: Dekel Peled To: Yongseok Koh CC: dev , Shahaf Shuler , Ori Kam , Andrew Rybchenko , "Yigit, Ferruh" , Thomas Monjalon , "Ananyev, Konstantin" , Adrien Mazarguil , Olivier Matz , Alex Rosenbaum Thread-Topic: [RFC v2] ethdev: support metadata as flow rule criteria Thread-Index: AQHUPweH2O7PuwmvXEqTAnL+blJ1KKTWPzxg Date: Wed, 29 Aug 2018 06:33:18 +0000 Message-ID: References: <1534146418-1060-1-git-send-email-dekelp@mellanox.com> <1535292577-47552-1-git-send-email-dekelp@mellanox.com> <22F57F34-98AA-4B57-8410-6023DEA1A332@mellanox.com> In-Reply-To: <22F57F34-98AA-4B57-8410-6023DEA1A332@mellanox.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=dekelp@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1SPR8PMB101; 6:gMi+23NoMJmlb2qrYbsKFqztED3m3RnURYUw70rO2/nKDRTuo9jiqG/zgfJW79AFrP1gz9vUA5tKpp+z1ZYBGur0eRnwgkRRCfSa1HOl8GDhueby0khSiU9+BUIc4vW++2hzgLOFC3qnGhbsISGReRMIkuXXMzEeS2R+y8eqmWgQNLzEad66YnQf2BjEa9wpD2fwY8T9F+YtLkq2osGS/WP4ffjftjyzIpazsTSI/kHOl++NuBC19DTTnbmO04W0niAjVIrSTcP6ylvAeEa2iDTMnweeXX0OXoHAYbivlHm8iojDd8/Svcb5wB7KWNgB2Vw9Sy17xoAeyRM0jxenmNpu4YUr7mH+6omUIICxK9Ll5CJ/J5o/qO8P1Y2Kzhsjp8rA8c5yzFj3n7FdhCzCEuDmPiJN2MCZTq7fg3uP8FpDHzQYa59jDWSLOy5eGnipcidYkchWv2IzytVIBoUMig==; 5:khlr7sK5oR6LliVnv6gynnsgk7RmQ3FNsIqq8TFomYIPUD0OY8zjRJKGe9ahCgHsG1mO+p7GNGrb07FA+Ki1B8b9Jq8E8CSSQZ3Va7illL+iGm/Cwvo1GEo5CByLo7k9xQPZVHVlitbaGMrLtp7GekfPNindkLlL51S4UudVfgM=; 7:rMjhBqjRImVnmoUilJlk0DSXWb+yRzj/FTMimnaJrlBVDrMlSjLigHUISOmvhVFf5j8SXRoh1nYG6YlFS+Wb3GJXP1q7qGu4t7nxKBI9ezb+2bIM7WFp2PGpuNzOCSuLJrruTK69t2mU/td9yGCPugZxtpWb6C+VNcocUEiyiI7nzp6otDw5IQheA49kuV7dyVVG6t+4pFLAyHltj97T1u5AQ+K2ICpunFEaqbGYV4r46rc5pVrVmNRLkCdg2puG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 20729211-4728-4feb-3d34-08d60d794f4a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1SPR8PMB101; x-ms-traffictypediagnostic: VI1SPR8PMB101: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823301075)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699016); SRVR:VI1SPR8PMB101; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR8PMB101; x-forefront-prvs: 077929D941 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(136003)(396003)(366004)(13464003)(199004)(189003)(6116002)(76176011)(476003)(14444005)(6636002)(86362001)(66066001)(105586002)(2900100001)(5660300001)(74316002)(8676002)(7736002)(486006)(478600001)(14454004)(256004)(316002)(305945005)(3846002)(33656002)(9686003)(229853002)(8936002)(6436002)(68736007)(6246003)(54906003)(25786009)(102836004)(107886003)(81156014)(81166006)(99286004)(11346002)(97736004)(446003)(53936002)(5250100002)(4326008)(26005)(6862004)(6506007)(106356001)(2906002)(7696005)(53546011)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1SPR8PMB101; H:VI1PR05MB4224.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: QHDQX9Ai/EVgvPF0XX/2fOCf4J97S0yU+Ds/t7xdyKIS23w4OPu1JgoOEWpAdh5wZ07HqzApQQ43hquiHChoke2Kdhk91vn8DK1v0dce5SSpWC8EicaBammjjA5HUjqMas5rgAbhXJEDrkcwkuxt9seo1EeMw+Ojj4710tfk9TJgyXQJf2TCGIAk80d3DlXCQcQHm6Y+t4y8ZqBMkpIKRBrIDD//vLLm/z6MEN/wxN2o2EhBrvKteIJjKddCdOvA85EIAzS7/Aooq+Twr2AgqTsi1qnhbBtTLirdcWCC8qQ9wIzG6QJTAnP5vnHpqPL80x1Rc+oKlxMY/0jy2N+pwHqDw2KA/LZ6rVvU3M0RXMU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20729211-4728-4feb-3d34-08d60d794f4a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2018 06:33:19.0242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR8PMB101 Subject: Re: [dpdk-dev] [RFC v2] 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: Wed, 29 Aug 2018 06:33:22 -0000 > -----Original Message----- > From: Yongseok Koh > Sent: Tuesday, August 28, 2018 10:44 PM > To: Dekel Peled > Cc: dev ; Shahaf Shuler ; Ori Kam > ; Andrew Rybchenko ; > Yigit, Ferruh ; Thomas Monjalon > ; Ananyev, Konstantin > ; Adrien Mazarguil > ; Olivier Matz ; > Alex Rosenbaum > Subject: Re: [RFC v2] ethdev: support metadata as flow rule criteria >=20 > > On Aug 26, 2018, at 7:09 AM, 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. > > > > For example, consider a vswitch application which controls a set of > > VMs, 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 > > the encap action. > > > > This RFC adds support for additional metadata to use as 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 mbuf.hash.fdir.hi > > will be used to carry the metadata item. This field is used only in > > ingress packets, so using it for egress metadata will not cause conflic= ts. > > > > Application should set the packet metdata 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. > > > > 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 dedicated field, and set PKT_TX_METADATA flag. > > > > 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. > > > > 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. > > > > Comments are welcome. > > > > Signed-off-by: Dekel Peled > > --- > > v2: Use existing field in mbuf for metadata item, as suggested, instead > > of adding a new field. > > Metadata item size adjusted to 32 bits. > > --- > > 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 | 13 +++++++++++++ > > 4 files changed, 60 insertions(+) > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > index b305a72..560e45a 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 32 bit metadata item. > > + > > +- Default ``mask`` matches any 32 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`` | 32 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..eba3cc4 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 { > > + uint32_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_BE32(UINT32_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..77c1552 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 used > > * to store the MSS of UDP fragments. > > @@ -526,6 +531,14 @@ struct rte_mbuf { > > uint32_t hi; > > /**< First 4 flexible bytes or FD ID, dependent on > > PKT_RX_FDIR_* flag in ol_flags. */ > > + > > + /** > > + * Above item has optional use on egress: > > + * Application specific metadata value > > + * for flow rule match. > > + * Valid if PKT_TX_METADATA is set. > > + */ > > + >=20 > Hi Dekel, >=20 > I don't think we have reached to a conclusion?? I remember there were > three options. > 1) add a new 64bit field > 2) use userdata/udata64 > 3) use hash >=20 > I still prefer 1) but if people here think that more fields will have to = be added > in the near feature then 2) would be my next preference. But, if we just > have some unclear anxiety (like the depletion of IPv4 address :-), 1) wou= ld > still be good. >=20 > But, 3) is my least preference as a Rx mbuf still can have both flow ID a= nd > metadata. >=20 > We still need more input/discussion. Option 1 was not favored in discussions so far, see RFC email chain. Option 2 is unwanted since there may be applications using userdata/udata64= . Currently we see use of metadata in tx only, hence option 3 is preferred. >=20 > Thanks, > Yongseok >=20 > > } fdir; /**< Filter identifier if FDIR enabled */ > > struct { > > uint32_t lo; > > -- > > 1.8.3.1 > >