From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1D553A00C4; Thu, 31 Oct 2019 17:13:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 901B61C2F3; Thu, 31 Oct 2019 17:13:30 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70080.outbound.protection.outlook.com [40.107.7.80]) by dpdk.org (Postfix) with ESMTP id 1B6981C2A3 for ; Thu, 31 Oct 2019 17:13:29 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=anHAZgmfzwxmcQhzjnsqN5vKNVz6dmoDptKiTyFtqusCGAyHpaUhoBgZcjb3kBs80pzVLBCNzKmA8yZWNDnJd68zYhIfgx4oB6x8qh9L8dTMeqFDm36z4zF6o0ld6O/Ls8rH1AE0ycAyvEPLkiXAWFo4aLwgrRXERi0YFV19d2Um0N2AK3tShRj/DA4sbZW197Y/EInLG5VPgsel5aibQzzZGKhjWPAlp/xll97NX7P635NAOG0bvsPyBm6RPSlrCEYpQkFFX9KfLZqvglWWJ2EuQUUbnML57+qzm4ltrX3YfC0QNd+ZO2lmKJcAjKkvwYjiA/K7KMES3Tm6MFLhhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HuhNs3OrSXilQLXrFLIhlDe+D/QYCnUvDRGLyRKJft4=; b=J0fHLUqYgq9UNVD1AzNB0qoHDz02tuQnsE4XhqCW6pD0gAFiVies3J5rsUbhttbYgVwHWJyA7u9IpeuncRZj5aYyrZeB2dR3sEpND2G9Ejs8IQ2a/QwMTSxsfrINTs4lsdMcZMpgAl6iR6PZqIF9UMlpbRKiliikiIebKA3ZIYfmLY9ZT8PaHf109mlpnT2G3wszZDn1y0g7nC6uReyX4Svh5C1Jy/XpPsVcxqhngyx/wBVCpdmB9QW8bALBIKWzWDuDaw/px5x0HFKg4Khcz4/vyykOReDKhBwRp/nDKS5wuaM2wc8HoOf239hQY3zCXjlGTZdQ+hway+tIWZ6c6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HuhNs3OrSXilQLXrFLIhlDe+D/QYCnUvDRGLyRKJft4=; b=D7A77diNj6Mcbw1HVj5mxdruXUE+e2l+yzyFuqYt786zGO1hI5XSMsfBdsSCvl6DArfnuQLok8B4OjVHvLV+ucEDgzk27aeTTXdHi+9bnsYOISNQr2QQPsy3pPzrRx4HRrrCfsenUJhJSdhSTXwVbMR4FkEzYDrOEAMAtRBWsdM= Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (10.171.188.154) by AM4PR05MB3186.eurprd05.prod.outlook.com (10.171.191.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Thu, 31 Oct 2019 16:13:27 +0000 Received: from AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::edab:529f:d14e:d3b]) by AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::edab:529f:d14e:d3b%7]) with mapi id 15.20.2387.028; Thu, 31 Oct 2019 16:13:27 +0000 From: Slava Ovsiienko To: Olivier Matz CC: "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , Thomas Monjalon , "arybchenko@solarflare.com" , Ori Kam , Yongseok Koh Thread-Topic: [PATCH v7 1/2] ethdev: extend flow metadata Thread-Index: AQHVkAKCXD8ZVs0t4Eygs3CjhnBGvKd06x3A Date: Thu, 31 Oct 2019 16:13:27 +0000 Message-ID: References: <1572455548-23420-2-git-send-email-viacheslavo@mellanox.com> <1572527121-13133-1-git-send-email-viacheslavo@mellanox.com> <1572527121-13133-2-git-send-email-viacheslavo@mellanox.com> <20191031154728.m2yrkydqbo4jwglf@platinum> In-Reply-To: <20191031154728.m2yrkydqbo4jwglf@platinum> 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=viacheslavo@mellanox.com; x-originating-ip: [95.164.10.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 90e74fe4-28e1-4187-a117-08d75e1d4379 x-ms-traffictypediagnostic: AM4PR05MB3186:|AM4PR05MB3186: x-ms-exchange-purlcount: 2 x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr,ExtFwd x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(366004)(39860400002)(396003)(13464003)(189003)(199004)(45080400002)(8676002)(14454004)(81156014)(81166006)(8936002)(476003)(107886003)(7696005)(229853002)(6916009)(102836004)(478600001)(66066001)(76116006)(55016002)(26005)(6116002)(76176011)(52536014)(6246003)(186003)(99286004)(86362001)(66946007)(3846002)(5660300002)(66476007)(305945005)(33656002)(316002)(14444005)(25786009)(64756008)(66446008)(66556008)(74316002)(71200400001)(4326008)(30864003)(256004)(7736002)(2906002)(486006)(71190400001)(6436002)(446003)(11346002)(9686003)(6306002)(6506007)(966005)(54906003)(53546011)(559001)(579004)(309714004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB3186; H:AM4PR05MB3265.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P1vmC75iDKF+MCj2RrVsA27VF4URX8+tSqIcaxpcT1vQOXfhgLNyHCPe+12rJ1PKJ3/RO7NsM5hwJ/TR7jwb963S7WJjG+sRquy15rWgcjq4wm183KVsBqY7pPVKRf+4jF5bKtpo6bfb66T3IsS6t4QtA21D/xZzkr2NXnn6iY139TvJbY5Kzcwb1HbN7LkEEyUUs6p3qPJPlPQtqxLTK5oA2bg1f47aQz9DCYHqFrzhjMWrjiIekDq5TyUkzv52UcS0xHxcbdZTE8Xo2af6/TuIGwmjg/P6VStzOEGWCIfhvKC7SFrk4nc1b7F1P16KuGEC51DkJbtgN9WOt/jxnszofepXdiYHAgxsnnyb1LNRFrqlUpUmOKHI2IXOSdwnZJa7cPTmm/OtcYbKFrGemrwE1nKwZLycygBK+veIf3GDh0G/t12GAUp+KoV2Stpa 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: 90e74fe4-28e1-4187-a117-08d75e1d4379 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 16:13:27.4392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YNAABF09kIRAZbMuEWHWppeomJy4fQwF8fAZLWacpfXEVgGSBwvl36++NY6pTE964T9tae00vc9nzuejj0iI+wH0EJBVWUqSFaXeNeetSGc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3186 Subject: Re: [dpdk-dev] [PATCH v7 1/2] ethdev: extend flow metadata 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Olivier, > -----Original Message----- > From: Olivier Matz > Sent: Thursday, October 31, 2019 17:47 > To: Slava Ovsiienko > Cc: dev@dpdk.org; Matan Azrad ; Raslan > Darawsheh ; Thomas Monjalon > ; arybchenko@solarflare.com; Ori Kam > ; Yongseok Koh > Subject: Re: [PATCH v7 1/2] ethdev: extend flow metadata >=20 > Hi Slava, >=20 > One comment at the end. >=20 > On Thu, Oct 31, 2019 at 01:05:20PM +0000, Viacheslav Ovsiienko wrote: > > Currently, metadata can be set on egress path via mbuf tx_metadata > > field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META > matches metadata. > > > > This patch extends the metadata feature usability. > > > > 1) RTE_FLOW_ACTION_TYPE_SET_META > > > > When supporting multiple tables, Tx metadata can also be set by a rule > > and matched by another rule. This new action allows metadata to be set > > as a result of flow match. > > > > 2) Metadata on ingress > > > > There's also need to support metadata on ingress. Metadata can be set > > by SET_META action and matched by META item like Tx. The final value > > set by the action will be delivered to application via metadata > > dynamic field of mbuf which can be accessed by > > RTE_FLOW_DYNF_METADATA() macro or with > > rte_flow_dynf_metadata_set() and rte_flow_dynf_metadata_get() helper > > routines. PKT_RX_DYNF_METADATA flag will be set along with the data. > > > > The mbuf dynamic field must be registered by calling > > rte_flow_dynf_metadata_register() prior to use SET_META action. > > > > The availability of dynamic mbuf metadata field can be checked with > > rte_flow_dynf_metadata_avail() routine. > > > > If application is going to engage the metadata feature it registers > > the metadata dynamic fields, then PMD checks the metadata field > > availability and handles the appropriate fields in datapath. > > > > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be > > propagated to the other path depending on hardware capability. > > > > MARK and METADATA look similar and might operate in similar way, but > > not interacting. > > > > Initially, there were proposed two metadata related actions: > > > > - RTE_FLOW_ACTION_TYPE_FLAG > > - RTE_FLOW_ACTION_TYPE_MARK > > > > These actions set the special flag in the packet metadata, MARK action > > stores some specified value in the metadata storage, and, on the > > packet receiving PMD puts the flag and value to the mbuf and > > applications can see the packet was threated inside flow engine > > according to the appropriate RTE flow(s). MARK and FLAG are like some > > kind of gateway to transfer some per-packet information from the flow > > engine to the application via receiving datapath. Also, there is the > > item of type RTE_FLOW_ITEM_TYPE_MARK provided. It allows us to > extend > > the flow match pattern with the capability to match the metadata values > set by MARK/FLAG actions on other flows. > > > > From the datapath point of view, the MARK and FLAG are related to the > > receiving side only. It would useful to have the same gateway on the > > transmitting side and there was the feature of type > > RTE_FLOW_ITEM_TYPE_META was proposed. The application can fill the > > field in mbuf and this value will be transferred to some field in the > > packet metadata inside the flow engine. It did not matter whether > > these metadata fields are shared because of MARK and META items > > belonged to different domains (receiving and > > transmitting) and could be vendor-specific. > > > > So far, so good, DPDK proposes some entities to control metadata > > inside the flow engine and gateways to exchange these values on a > > per-packet basis via datapaths. > > > > As we can see, the MARK and META means are not symmetric, there is > > absent action which would allow us to set META value on the transmittin= g > path. > > So, the action of type: > > > > - RTE_FLOW_ACTION_TYPE_SET_META was proposed. > > > > The next, applications raise the new requirements for packet metadata. > > The flow ngines are getting more complex, internal switches are > > introduced, multiple ports might be supported within the same flow engi= ne > namespace. > > From the DPDK points of view, it means the packets might be sent on > > one eth_dev port and received on the other one, and the packet path > > inside the flow engine entirely belongs to the same hardware device. > > The simplest example is SR-IOV with PF, VFs and the representors. And > > there is a brilliant opportunity to provide some out-of-band channel > > to transfer some extra data from one port to another one, besides the > > packet data itself. And applications would like to use this opportunity= . > > > > It is supposed for application to use trials (with rte_flow_validate) > > to detect which metadata features (FLAG, MARK, META) actually > > supported by PMD and underlying hardware. It might depend on PMD > > configuration, system software, hardware settings, etc., and should be > > detected in run time. > > > > Signed-off-by: Yongseok Koh > > Signed-off-by: Viacheslav Ovsiienko > > Acked-by: Andrew Rybchenko > > Acked-by: Ori Kam > > --- > > v7: - updated release notes in collateral patch > > > > v6: - > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche > s.dpdk.org%2Fpatch%2F62245%2F&data=3D02%7C01%7Cviacheslavo%40 > mellanox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e > 4d9ba6a4d149256f461b%7C0%7C0%7C637081336535150897&sdata=3DlZ > SRRw5DmT1cGeJ7Q57x8qIJSsFLPC%2FrJpzH3Yp%2Bf2k%3D&reserved=3D > 0 > > - minor code style issues > > - is combined in series with followed egress metadata patch > > > > v5: - > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche > s.dpdk.org%2Fpatch%2F62179%2F&data=3D02%7C01%7Cviacheslavo%40 > mellanox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e > 4d9ba6a4d149256f461b%7C0%7C0%7C637081336535150897&sdata=3DL > EL91A7XH%2BXYJr19%2FxpcEUmzr2ZMITfUJu%2FY8IfnLR0%3D&reserv > ed=3D0 > > - addressed code style issues from comments > > - Tx metadata deprecation notice removed > > (dedicated tx_metadata patch is coming) > > - MBUF_DYNF_METADATA_NAME is splitted into FIELD and FLAG > > dedicated ones, RTE suffix is added > > - metadata historic retrospective is added to log message > > - rebased > > > > v4: - > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche > s.dpdk.org%2Fpatch%2F62065%2F&data=3D02%7C01%7Cviacheslavo%40 > mellanox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e > 4d9ba6a4d149256f461b%7C0%7C0%7C637081336535150897&sdata=3Dz > wSoQ0IhWjalmLqSv5CLSNtBt96FJwxmnZQOL%2FLIupw%3D&reserved=3D > 0 > > - documentation comments addressed > > - deprecation notice for Tx metadata offload flag > > - rebased > > > > v3: - > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche > s.dpdk.org%2Fpatch%2F61902%2F&data=3D02%7C01%7Cviacheslavo%40 > mellanox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e > 4d9ba6a4d149256f461b%7C0%7C0%7C637081336535150897&sdata=3D > %2FvKJWyFvCaBeDQVfpsKM4HL8fzXFoGKHWbQn%2FjBtulM%3D&reser > ved=3D0 > > - rebased, neat updates > > > > v2: - > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatch > > > es.dpdk.org%2Fpatch%2F60909%2F&data=3D02%7C01%7Cviacheslavo%4 > 0mellan > > > ox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e4d9ba > 6a4d14925 > > > 6f461b%7C0%7C0%7C637081336535150897&sdata=3DlEb4sLRWVXuvaL > WLHENHZNMr > > 4EwFuFs8LoglfikJqFE%3D&reserved=3D0 > > > > v1: - > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche > s.dpdk.org%2Fpatch%2F56104%2F&data=3D02%7C01%7Cviacheslavo%40 > mellanox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e > 4d9ba6a4d149256f461b%7C0%7C0%7C637081336535150897&sdata=3D > %2FNYTARUn%2FqNn9BRBK09juCiGYS1eACb1OxEZKJJMSY4%3D&reser > ved=3D0 > > - rfc: > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatch > > > es.dpdk.org%2Fpatch%2F54271%2F&data=3D02%7C01%7Cviacheslavo%4 > 0mellan > > > ox.com%7C1390029b214e4543f1e708d75e19a404%7Ca652971c7d2e4d9ba > 6a4d14925 > > > 6f461b%7C0%7C0%7C637081336535150897&sdata=3Du0faxda7EuxmoHk > Ty0r0d4Yw > > z6JfPvkiQuZEss6oo%2B4%3D&reserved=3D0 > > > > app/test-pmd/cmdline_flow.c | 57 ++++++++++++++++- > > app/test-pmd/util.c | 5 ++ > > doc/guides/prog_guide/rte_flow.rst | 72 ++++++++++++++++----- > > doc/guides/rel_notes/release_19_11.rst | 13 ++++ > > lib/librte_ethdev/rte_ethdev_version.map | 3 + > > lib/librte_ethdev/rte_flow.c | 40 ++++++++++++ > > lib/librte_ethdev/rte_flow.h | 103 > +++++++++++++++++++++++++++++-- > > lib/librte_mbuf/rte_mbuf_dyn.h | 8 ++- > > 8 files changed, 279 insertions(+), 22 deletions(-) > > > > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c > > index 0d0bc0a..e4ef066 100644 > > --- a/app/test-pmd/cmdline_flow.c > > +++ b/app/test-pmd/cmdline_flow.c > > @@ -316,6 +316,9 @@ enum index { > > ACTION_RAW_ENCAP_INDEX_VALUE, > > ACTION_RAW_DECAP_INDEX, > > ACTION_RAW_DECAP_INDEX_VALUE, > > + ACTION_SET_META, > > + ACTION_SET_META_DATA, > > + ACTION_SET_META_MASK, > > }; > > > > /** Maximum size for pattern in struct rte_flow_item_raw. */ @@ > > -1067,6 +1070,7 @@ struct parse_action_priv { > > ACTION_DEC_TCP_ACK, > > ACTION_RAW_ENCAP, > > ACTION_RAW_DECAP, > > + ACTION_SET_META, > > ZERO, > > }; > > > > @@ -1265,6 +1269,13 @@ struct parse_action_priv { > > ZERO, > > }; > > > > +static const enum index action_set_meta[] =3D { > > + ACTION_SET_META_DATA, > > + ACTION_SET_META_MASK, > > + ACTION_NEXT, > > + ZERO, > > +}; > > + > > static int parse_set_raw_encap_decap(struct context *, const struct to= ken > *, > > const char *, unsigned int, > > void *, unsigned int); > > @@ -1329,6 +1340,10 @@ static int > > parse_vc_action_raw_encap_index(struct context *, static int > parse_vc_action_raw_decap_index(struct context *, > > const struct token *, const char *, > > unsigned int, void *, unsigned int); > > +static int parse_vc_action_set_meta(struct context *ctx, > > + const struct token *token, const char *str, > > + unsigned int len, void *buf, > > + unsigned int size); > > static int parse_destroy(struct context *, const struct token *, > > const char *, unsigned int, > > void *, unsigned int); > > @@ -3378,7 +3393,31 @@ static int comp_set_raw_index(struct context > *, const struct token *, > > .help =3D "index of raw_encap/raw_decap data", > > .next =3D NEXT(next_item), > > .call =3D parse_port, > > - } > > + }, > > + [ACTION_SET_META] =3D { > > + .name =3D "set_meta", > > + .help =3D "set metadata", > > + .priv =3D PRIV_ACTION(SET_META, > > + sizeof(struct rte_flow_action_set_meta)), > > + .next =3D NEXT(action_set_meta), > > + .call =3D parse_vc_action_set_meta, > > + }, > > + [ACTION_SET_META_DATA] =3D { > > + .name =3D "data", > > + .help =3D "metadata value", > > + .next =3D NEXT(action_set_meta, NEXT_ENTRY(UNSIGNED)), > > + .args =3D ARGS(ARGS_ENTRY_HTON > > + (struct rte_flow_action_set_meta, data)), > > + .call =3D parse_vc_conf, > > + }, > > + [ACTION_SET_META_MASK] =3D { > > + .name =3D "mask", > > + .help =3D "mask for metadata value", > > + .next =3D NEXT(action_set_meta, NEXT_ENTRY(UNSIGNED)), > > + .args =3D ARGS(ARGS_ENTRY_HTON > > + (struct rte_flow_action_set_meta, mask)), > > + .call =3D parse_vc_conf, > > + }, > > }; > > > > /** Remove and return last entry from argument stack. */ @@ -4818,6 > > +4857,22 @@ static int comp_set_raw_index(struct context *, const struc= t > token *, > > return ret; > > } > > > > +static int > > +parse_vc_action_set_meta(struct context *ctx, const struct token *toke= n, > > + const char *str, unsigned int len, void *buf, > > + unsigned int size) > > +{ > > + int ret; > > + > > + ret =3D parse_vc(ctx, token, str, len, buf, size); > > + if (ret < 0) > > + return ret; > > + ret =3D rte_flow_dynf_metadata_register(); > > + if (ret < 0) > > + return -1; > > + return len; > > +} > > + > > /** Parse tokens for destroy command. */ static int > > parse_destroy(struct context *ctx, const struct token *token, diff > > --git a/app/test-pmd/util.c b/app/test-pmd/util.c index > > f20531d..56075b3 100644 > > --- a/app/test-pmd/util.c > > +++ b/app/test-pmd/util.c > > @@ -82,6 +82,11 @@ > > mb->vlan_tci, mb->vlan_tci_outer); > > else if (ol_flags & PKT_RX_VLAN) > > printf(" - VLAN tci=3D0x%x", mb->vlan_tci); > > + if (ol_flags & PKT_TX_METADATA) > > + printf(" - Tx metadata: 0x%x", mb->tx_metadata); > > + if (ol_flags & PKT_RX_DYNF_METADATA) > > + printf(" - Rx metadata: 0x%x", > > + *RTE_FLOW_DYNF_METADATA(mb)); > > if (mb->packet_type) { > > rte_get_ptype_name(mb->packet_type, buf, > sizeof(buf)); > > printf(" - hw ptype: %s", buf); > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > index 159ce19..c943aca 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -658,6 +658,32 @@ the physical device, with virtual groups in the > PMD or not at all. > > | ``mask`` | ``id`` | zeroed to match any value | > > +----------+----------+---------------------------+ > > > > +Item: ``META`` > > +^^^^^^^^^^^^^^^^^ > > + > > +Matches 32 bit metadata item set. > > + > > +On egress, metadata can be set either by mbuf metadata field with > > +PKT_TX_METADATA flag or ``SET_META`` action. On ingress, > ``SET_META`` > > +action sets metadata for a packet and the metadata will be reported > > +via ``metadata`` dynamic field of ``rte_mbuf`` with > PKT_RX_DYNF_METADATA flag. > > + > > +- Default ``mask`` matches the specified Rx metadata 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=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`` | bit-mask applies to "spec" and "last" | > > + +----------+----------+---------------------------------------+ > > + > > Data matching item types > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > > > @@ -1232,21 +1258,6 @@ Matches a PPPoE session protocol identifier. > > - ``proto_id``: PPP protocol identifier. > > - Default ``mask`` matches proto_id only. > > > > - > > -.. _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=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`` | bit-mask applies to "spec" and "last" | > > - +----------+----------+---------------------------------------+ > > - > > Item: ``NSH`` > > ^^^^^^^^^^^^^ > > > > @@ -2466,6 +2477,37 @@ Value to decrease TCP acknowledgment > number by is a big-endian 32 bit integer. > > > > Using this action on non-matching traffic will result in undefined beh= avior. > > > > +Action: ``SET_META`` > > +^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +Set metadata. Item ``META`` matches metadata. > > + > > +Metadata set by mbuf metadata field with PKT_TX_METADATA flag on > > +egress will be overridden by this action. On ingress, the metadata > > +will be carried by ``metadata`` dynamic field of ``rte_mbuf`` which > > +can be accessed by ``RTE_FLOW_DYNF_METADATA()``. > PKT_RX_DYNF_METADATA > > +flag will be set along with the data. > > + > > +The mbuf dynamic field must be registered by calling > > +``rte_flow_dynf_metadata_register()`` prior to use ``SET_META`` action= . > > + > > +Altering partial bits is supported with ``mask``. For bits which have > > +never been set, unpredictable value will be seen depending on driver > > +implementation. For loopback/hairpin packet, metadata set on Rx/Tx > > +may or may not be propagated to the other path depending on HW > capability. > > + > > +.. _table_rte_flow_action_set_meta: > > + > > +.. table:: SET_META > > + > > + +----------+----------------------------+ > > + | Field | 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+ > > + | ``data`` | 32 bit metadata value | > > + +----------+----------------------------+ > > + | ``mask`` | bit-mask applies to "data" | > > + +----------+----------------------------+ > > + > > Negative types > > ~~~~~~~~~~~~~~ > > > > diff --git a/doc/guides/rel_notes/release_19_11.rst > > b/doc/guides/rel_notes/release_19_11.rst > > index f6e90cb..963c4f8 100644 > > --- a/doc/guides/rel_notes/release_19_11.rst > > +++ b/doc/guides/rel_notes/release_19_11.rst > > @@ -237,6 +237,14 @@ New Features > > On supported NICs, we can now setup haipin queue which will offload > packets > > from the wire, backto the wire. > > > > +* **Extended metadata support in rte_flow.** > > + > > + Flow metadata is extended to both Rx and Tx. > > + > > + * Tx metadata can also be set by SET_META action of rte_flow. > > + * Rx metadata is delivered to host via a dynamic field of ``rte_mbuf= `` > with > > + PKT_RX_DYNF_METADATA. > > + > > > > Removed Items > > ------------- > > @@ -344,6 +352,11 @@ API Changes > > has been introduced in this release is used when used when all the > packets > > enqueued in the tx adapter are destined for the same Ethernet port &= Tx > queue. > > > > +* metadata: RTE_FLOW_ITEM_TYPE_META data endianness altered to > host one. > > + Due to the new dynamic metadata field in mbuf is host-endian > > +either, there > > + is the minor compatibility issue for applications in case of 32-bit > > +values > > + supported. > > + > > * sched: The pipe nodes configuration parameters such as number of > pipes, > > pipe queue sizes, pipe profiles, etc., are moved from port level str= ucture > > to subport level. This allows different subports of the same port > > to diff --git a/lib/librte_ethdev/rte_ethdev_version.map > > b/lib/librte_ethdev/rte_ethdev_version.map > > index 48b5389..e593f34 100644 > > --- a/lib/librte_ethdev/rte_ethdev_version.map > > +++ b/lib/librte_ethdev/rte_ethdev_version.map > > @@ -291,4 +291,7 @@ EXPERIMENTAL { > > rte_eth_rx_hairpin_queue_setup; > > rte_eth_tx_hairpin_queue_setup; > > rte_eth_dev_hairpin_capability_get; > > + rte_flow_dynf_metadata_offs; > > + rte_flow_dynf_metadata_mask; > > + rte_flow_dynf_metadata_register; > > }; > > diff --git a/lib/librte_ethdev/rte_flow.c > > b/lib/librte_ethdev/rte_flow.c index ca0f680..b0490cd 100644 > > --- a/lib/librte_ethdev/rte_flow.c > > +++ b/lib/librte_ethdev/rte_flow.c > > @@ -12,10 +12,18 @@ > > #include > > #include > > #include > > +#include > > +#include > > #include "rte_ethdev.h" > > #include "rte_flow_driver.h" > > #include "rte_flow.h" > > > > +/* Mbuf dynamic field name for metadata. */ int > > +rte_flow_dynf_metadata_offs =3D -1; > > + > > +/* Mbuf dynamic field flag bit number for metadata. */ uint64_t > > +rte_flow_dynf_metadata_mask; > > + > > /** > > * Flow elements description tables. > > */ > > @@ -157,8 +165,40 @@ struct rte_flow_desc_data { > > MK_FLOW_ACTION(DEC_TCP_SEQ, sizeof(rte_be32_t)), > > MK_FLOW_ACTION(INC_TCP_ACK, sizeof(rte_be32_t)), > > MK_FLOW_ACTION(DEC_TCP_ACK, sizeof(rte_be32_t)), > > + MK_FLOW_ACTION(SET_META, sizeof(struct > rte_flow_action_set_meta)), > > }; > > > > +int > > +rte_flow_dynf_metadata_register(void) > > +{ > > + int offset; > > + int flag; > > + > > + static const struct rte_mbuf_dynfield desc_offs =3D { > > + .name =3D RTE_MBUF_DYNFIELD_METADATA_NAME, > > + .size =3D sizeof(uint32_t), > > + .align =3D __alignof__(uint32_t), > > + }; > > + static const struct rte_mbuf_dynflag desc_flag =3D { > > + .name =3D RTE_MBUF_DYNFLAG_METADATA_NAME, > > + }; > > + > > + offset =3D rte_mbuf_dynfield_register(&desc_offs); > > + if (offset < 0) > > + goto error; > > + flag =3D rte_mbuf_dynflag_register(&desc_flag); > > + if (flag < 0) > > + goto error; > > + rte_flow_dynf_metadata_offs =3D offset; > > + rte_flow_dynf_metadata_mask =3D (1ULL << flag); > > + return 0; > > + > > +error: > > + rte_flow_dynf_metadata_offs =3D -1; > > + rte_flow_dynf_metadata_mask =3D 0ULL; > > + return -rte_errno; > > +} > > + > > static int > > flow_err(uint16_t port_id, int ret, struct rte_flow_error *error) { > > diff --git a/lib/librte_ethdev/rte_flow.h > > b/lib/librte_ethdev/rte_flow.h index 4fee105..f6e050c 100644 > > --- a/lib/librte_ethdev/rte_flow.h > > +++ b/lib/librte_ethdev/rte_flow.h > > @@ -28,6 +28,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > > > #ifdef __cplusplus > > extern "C" { > > @@ -418,7 +420,8 @@ enum rte_flow_item_type { > > /** > > * [META] > > * > > - * Matches a metadata value specified in mbuf metadata field. > > + * Matches a metadata value. > > + * > > * See struct rte_flow_item_meta. > > */ > > RTE_FLOW_ITEM_TYPE_META, > > @@ -1263,18 +1266,23 @@ struct rte_flow_item_icmp6_nd_opt_tla_eth { > > #endif > > > > /** > > - * RTE_FLOW_ITEM_TYPE_META. > > + * RTE_FLOW_ITEM_TYPE_META > > * > > - * Matches a specified metadata value. > > + * Matches a specified metadata value. On egress, metadata can be set > > + either by > > + * mbuf tx_metadata field with PKT_TX_METADATA flag or > > + * RTE_FLOW_ACTION_TYPE_SET_META. On ingress, > > + RTE_FLOW_ACTION_TYPE_SET_META sets > > + * metadata for a packet and the metadata will be reported via mbuf > > + metadata > > + * dynamic field with PKT_RX_DYNF_METADATA flag. The dynamic mbuf > > + field must be > > + * registered in advance by rte_flow_dynf_metadata_register(). > > */ > > struct rte_flow_item_meta { > > - rte_be32_t data; > > + 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), > > + .data =3D UINT32_MAX, > > }; > > #endif > > > > @@ -1942,6 +1950,13 @@ enum rte_flow_action_type { > > * undefined behavior. > > */ > > RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK, > > + > > + /** > > + * Set metadata on ingress or egress path. > > + * > > + * See struct rte_flow_action_set_meta. > > + */ > > + RTE_FLOW_ACTION_TYPE_SET_META, > > }; > > > > /** > > @@ -2429,6 +2444,57 @@ struct rte_flow_action_set_mac { > > uint8_t mac_addr[RTE_ETHER_ADDR_LEN]; }; > > > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this structure may change without prior notice > > + * > > + * RTE_FLOW_ACTION_TYPE_SET_META > > + * > > + * Set metadata. Metadata set by mbuf tx_metadata field with > > + * PKT_TX_METADATA flag on egress will be overridden by this action. > > +On > > + * ingress, the metadata will be carried by mbuf metadata dynamic > > +field > > + * with PKT_RX_DYNF_METADATA flag if set. The dynamic mbuf field > > +must be > > + * registered in advance by rte_flow_dynf_metadata_register(). > > + * > > + * Altering partial bits is supported with mask. For bits which have > > +never > > + * been set, unpredictable value will be seen depending on driver > > + * implementation. For loopback/hairpin packet, metadata set on Rx/Tx > > +may > > + * or may not be propagated to the other path depending on HW > capability. > > + * > > + * RTE_FLOW_ITEM_TYPE_META matches metadata. > > + */ > > +struct rte_flow_action_set_meta { > > + uint32_t data; > > + uint32_t mask; > > +}; > > + > > +/* Mbuf dynamic field offset for metadata. */ extern int > > +rte_flow_dynf_metadata_offs; > > + > > +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t > > +rte_flow_dynf_metadata_mask; > > + > > +/* Mbuf dynamic field pointer for metadata. */ #define > > +RTE_FLOW_DYNF_METADATA(m) \ > > + RTE_MBUF_DYNFIELD((m), rte_flow_dynf_metadata_offs, uint32_t > *) > > + > > +/* Mbuf dynamic flag for metadata. */ #define PKT_RX_DYNF_METADATA > > +(rte_flow_dynf_metadata_mask) > > + > > +__rte_experimental > > +static inline uint32_t > > +rte_flow_dynf_metadata_get(struct rte_mbuf *m) { > > + return *RTE_FLOW_DYNF_METADATA(m); > > +} > > + > > +__rte_experimental > > +static inline void > > +rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v) { > > + *RTE_FLOW_DYNF_METADATA(m) =3D v; > > +} > > + > > /* > > * Definition of a single action. > > * > > @@ -2662,6 +2728,33 @@ enum rte_flow_conv_op { }; > > > > /** > > + * Check if mbuf dynamic field for metadata is registered. > > + * > > + * @return > > + * True if registered, false otherwise. > > + */ > > +__rte_experimental > > +static inline int > > +rte_flow_dynf_metadata_avail(void) > > +{ > > + return !!rte_flow_dynf_metadata_mask; } > > + > > +/** > > + * Register mbuf dynamic field and flag for metadata. > > + * > > + * This function must be called prior to use SET_META action in order > > +to > > + * register the dynamic mbuf field. Otherwise, the data cannot be > > +delivered to > > + * application. > > + * > > + * @return > > + * 0 on success, a negative errno value otherwise and rte_errno is s= et. > > + */ > > +__rte_experimental > > +int > > +rte_flow_dynf_metadata_register(void); > > + > > +/** > > * Check whether a flow rule can be created on a given port. > > * > > * The flow rule is validated for correctness and whether it could be > > accepted diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h > > b/lib/librte_mbuf/rte_mbuf_dyn.h index 2e9d418..de651c1 100644 > > --- a/lib/librte_mbuf/rte_mbuf_dyn.h > > +++ b/lib/librte_mbuf/rte_mbuf_dyn.h > > @@ -234,6 +234,12 @@ int rte_mbuf_dynflag_lookup(const char *name, > > __rte_experimental void rte_mbuf_dyn_dump(FILE *out); > > > > -/* Placeholder for dynamic fields and flags declarations. */ > > +/* > > + * Placeholder for dynamic fields and flags declarations. > > + * This is centralizing point to gather all field names > > + * and parameters together. > > + */ > > +#define RTE_MBUF_DYNFIELD_METADATA_NAME > "rte_flow_dynfield_metadata" > > +#define RTE_MBUF_DYNFLAG_METADATA_NAME > "rte_flow_dynflag_metadata" > > >=20 > Sorry if it was not clear in my first comment, but I think we should have= some > words in this file about what are these field/flag. Sure, I'll add some not-too-wordy comment here. >=20 > After that: > Acked-by: Olivier Matz Thanks a lot for the review, we polished the patch and made one better. With best regards, Slava