From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50080.outbound.protection.outlook.com [40.107.5.80]) by dpdk.org (Postfix) with ESMTP id 0D7ED1D8A for ; Tue, 28 Aug 2018 21:44:28 +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=UglbmU/YMg3/j40RNIFGR448sNMNBQLoDGD0PgvXJlw=; b=t9I7LeapjAfaS/sqGg3YUMGMERN7NAz94heORhWgXRklkpmWK/BQRZVP1HUAGFAcAYz0TIW6+LE2DDap/QwCfF/4PXVnf6z6QZFdbfC0o+c3x9uoc0NNbckVnDwrnu3vZWx5Sz9UwaQOsrnB8m45PwkpfgOc9vkpkJKXaq0WhCw= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4073.eurprd05.prod.outlook.com (52.134.72.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.13; Tue, 28 Aug 2018 19:44:26 +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:44:26 +0000 From: Yongseok Koh To: Dekel Peled 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: AQHUPUaUPaTH0FZh+EKdzSMcKjzHoKTVlH4A Date: Tue, 28 Aug 2018 19:44:26 +0000 Message-ID: <22F57F34-98AA-4B57-8410-6023DEA1A332@mellanox.com> References: <1534146418-1060-1-git-send-email-dekelp@mellanox.com> <1535292577-47552-1-git-send-email-dekelp@mellanox.com> In-Reply-To: <1535292577-47552-1-git-send-email-dekelp@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=yskoh@mellanox.com; x-originating-ip: [2607:fb90:4afa:9ebd:bd01:1265:52d4:2d3d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4073; 6:pZCmPFsmPBkKdAjj/Q8eb/p+TtdzbUnfPLJoVJPwY7/4JzvpX2loAe4ISbMrEbW/nNkBdzrs327ZNt4kY6WMCVdBBWflWefSw8xKXtyMQp6ELdw6L2IdisnZ2VXr5DXdH2AuMU9+RFmfp0sTwSxePzHnwt7DewXziK3CtG6qIqir57ne7qnJyJU/DhrVxVN5zR9Vt1afgcSdCHjkrJddIojL4PFkj2iqW2L/Oaj3tQMk/9NkdAzcGIUMMzwrzbUYCeJbDNL2TSxOrJZlZOK6llvXgRcbKNeZGRevhE1UHZdfZBRfT1PzMQ0SqqvORxlw1UBdnIOc0xOT5A4PbSnRgnzrM4vjcZAA3gWp+1t/+vOIsHpwa+X4H2FjCaPFKBXH4Zy8JweziwE0WM2SiUk+WffEAhbwVHXNlKEUC7UWSAOj2Px0MjLOCmqVCNAeLop3eYsELTDouQHyRwzLq9I20g==; 5:uwFoLm0fsRiymcBZXy2ZJ7o0PtqxKZSbJzzQGiPj79G4hHDyQREcqbw7WDEgj78MzLLJD/bmftDU1fZwNryxTEyS265oE5qwRdC5rJji+uoDZJAFQuocurqyWfBaES8CD7LeLDMqwZ71OjcqB3qHDOeguFpZip9CBqzwbpmy8Ms=; 7:+4/stA8vfcrNAhkZ3JxpGktmdjA5ITovqT32k03SwNkZRd61BZf0G+urzosFmcNMyJykR7jPKHdBMFVCxQTNP+lU08xHyd8Qw+uo1ZdAEP2Fu8a5hXt7j4iNAdM9AILJxu2gWQtOF3xYIxxcMa/DrhdrKukazrkD5Jmx+ce3jdjDMJzLo++E/p4ONJRH4O0VBHrjnrCdgS0QcosAlb+VUjvZjbt1qp2hIYiFp+txq9M0pnSsNnz6rkrIoEf91a7c x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 56f42381-61f6-4144-08de-08d60d1ea9c6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0502MB4073; x-ms-traffictypediagnostic: DB3PR0502MB4073: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823301075)(93006095)(93001095)(10201501046)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699016); SRVR:DB3PR0502MB4073; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4073; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(39860400002)(396003)(199004)(189003)(446003)(478600001)(5660300001)(476003)(2616005)(53936002)(6512007)(81156014)(81166006)(6506007)(6436002)(46003)(11346002)(6486002)(4326008)(68736007)(53546011)(83716003)(102836004)(229853002)(33656002)(25786009)(2906002)(256004)(14444005)(6636002)(97736004)(54906003)(6246003)(5250100002)(6116002)(36756003)(8676002)(6862004)(76176011)(86362001)(107886003)(8936002)(486006)(105586002)(305945005)(37006003)(106356001)(316002)(14454004)(2900100001)(7736002)(82746002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4073; 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: 26hDntNoH+0v075gPXG4wxjH/tC0UxTlWmH6PR6Kkmm+gqs42eF0D97PEDA3p+UJLAdlayuCRmmHvHZVcm6PkrnfS0pQqeCnebtpsK9Q7s0MJsJtZ1hEzR4bFSNQ+I1M483rBTGMYTLIJ3PA2zgUBex/99bRNBJezOudRuxAYZtmYltv6tilpzMP3nXzKuiytT96hwih2UMTgBA86xjOCRLnj39srDJOYTnloAbXKJ7dcceK9tbMRhgpJCWXamHG03qPOt7pWEWYOk4eQC/1kg9aNA9SdI0BFVCOWv75Qfcg5AO+XvAVl/iOsCj6s7RxwQWZ+5sUICADQlQfXjKzulI/5gANz4YrO3VFJjI72bA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56f42381-61f6-4144-08de-08d60d1ea9c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2018 19:44:26.5660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4073 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: Tue, 28 Aug 2018 19:44:28 -0000 > On Aug 26, 2018, at 7:09 AM, Dekel Peled wrote: >=20 > 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 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. >=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 > 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 conflicts= . >=20 > 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. >=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 dedicated 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. >=20 > Comments are welcome. >=20 > Signed-off-by: Dekel Peled > --- > v2: Use existing field in mbuf for metadata item, as suggested, instead=20 > 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(+) >=20 > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/r= te_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`_ >=20 > +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 > ~~~~~~~ >=20 > 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)), > }; >=20 > /** 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, > }; >=20 > /** > @@ -849,6 +858,22 @@ struct rte_flow_item_gre { > #endif >=20 > /** > + * 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 */ >=20 > /** > + * 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. > + */ > + Hi Dekel, 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 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 j= ust have some unclear anxiety (like the depletion of IPv4 address :-), 1) would still be good. But, 3) is my least preference as a Rx mbuf still can have both flow ID and metadata. We still need more input/discussion. Thanks, Yongseok > } fdir; /**< Filter identifier if FDIR enabled */ > struct { > uint32_t lo; > --=20 > 1.8.3.1 >=20