From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0A07DA0C47; Tue, 12 Oct 2021 08:41:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 944DB4067C; Tue, 12 Oct 2021 08:41:40 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2072.outbound.protection.outlook.com [40.107.236.72]) by mails.dpdk.org (Postfix) with ESMTP id 6CD7240142 for ; Tue, 12 Oct 2021 08:41:38 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=llwdbuAHjRIk5RaEdHiQ9Q/diNLJkIw2j97zsGYvtbdYSPT2daTAOdNKoLOvthjKnGmUp22wgg2vOUF+PCOkN9Ijj0ZxJA5euEYodCOag73ezb62AKdkSFQp1i9K1iLrl8CGOY2fV/5pHstkk43yHP0OauUlwSfWxVEV849j7o2WQX/xLwSeRnDc+pei0ACfB3CHctoJDDMv1XsmYjxuktcgjYFWYIiYpWht7jYRaAJcNrTkEp1wl3zolDKa9FFQD4HGLj3tpOr9XbyVO3jC47/0FrVwdvng4eIorPDaH3UzSXFJKD3GcP//Mob+4sWBksH1po87/bGosj9R1zKpHA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jk7QlzVDTXy3YWJXsZTgQ1WglEOWrZLuVdl9FARnfko=; b=F+buNyL4AgnIoFdSWN8PJTS5VWUqTLOyBBBwXB5q8jQXCNLMtI2sQVDi7ujGA3tbynJRBRWEePYcYhOCx2PRRb/CXwu4f5QF4OHUZRDRYSWLbVA/hSQmIk+C+0bnSwKAQnvRj9XTjf+loTcuqVHjeu4FuB6+EfQ/22FyTeafungY4Vjc5GSAr1bd26hpMH0Wwi+voFIZwAOBaCAFKJDedAbJPTAfsDVxQ12uYxbG7BV+mNxucWdajPG92tdrOYd/mG9kNix+qA3if5K+jj0yTsOCJT5zq2gprPWsuO6twa+QQF+G2AbRxTGTzGc9XzITyycIf3ttkPiEeBcRwfcKOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jk7QlzVDTXy3YWJXsZTgQ1WglEOWrZLuVdl9FARnfko=; b=oO/2eY3D6u1oEQXv+Guwn7/5k38QuOyHa71xjcyYQHFMsz55Gj+CQ6HKQ/5uNoK1Z3Ww/r8OljLbFX8L4SvNls6oov8bPiFS8WpMee7XyWsXf6kGsRyH8dqs/Xoe8adVPOF248Gs01MqvJNKh5rPbMG+a/QESNBym1AzCgF8/7H2Mb4RnaaJjMIWuLYst+XEVuuU6QkHI8RxpBjfZRBPFeDRAv/URmIqTo0SCqR9KqcLxUsVhtbaBEs8PMNh5TmtTt66kdezjDziniNWd223iUflqdrTxEm3xDRw4a7o46TQFN84LbKvLR7QMDva6QqVo4g3zBgV8QGBktl0JiZRVA== Received: from DM8PR12MB5400.namprd12.prod.outlook.com (2603:10b6:8:3b::12) by DM8PR12MB5445.namprd12.prod.outlook.com (2603:10b6:8:24::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Tue, 12 Oct 2021 06:41:37 +0000 Received: from DM8PR12MB5400.namprd12.prod.outlook.com ([fe80::d03d:1f75:ca20:6a32]) by DM8PR12MB5400.namprd12.prod.outlook.com ([fe80::d03d:1f75:ca20:6a32%6]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 06:41:37 +0000 From: Ori Kam To: Slava Ovsiienko , "dev@dpdk.org" CC: Raslan Darawsheh , Matan Azrad , Shahaf Shuler , Gregory Etelson , NBU-Contact-Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v3 1/5] ethdev: introduce configurable flexible item Thread-Index: AQHXvswNkBbjFrjbJ02BhNvn0Gt8EavO6eFA Date: Tue, 12 Oct 2021 06:41:36 +0000 Message-ID: References: <20210922180418.20663-1-viacheslavo@nvidia.com> <20211011181528.517-1-viacheslavo@nvidia.com> <20211011181528.517-2-viacheslavo@nvidia.com> In-Reply-To: <20211011181528.517-2-viacheslavo@nvidia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18641699-8594-4939-6b7f-08d98d4b56ef x-ms-traffictypediagnostic: DM8PR12MB5445: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7HbJjSgbCbY+PZdeHj+3858kPDJ+TIzIQT5o7WxYF1r60/4p1Un7zesF7O9xQx9caFr1dNc+3CWex+DcNMmkIbbpH/ObNBkX/LjDZvIQpqteORFtmb4QSggR+l5c35ayAY6qn+0z4ddMAIW/UbIMzURfu7UpHtzr7Ya/9/3jBh2bIcVjml9KpomxRGlOtcylQAt2+yj+fN5spYJu3QykNjvOmYwIB1/w3kGZ2jgMxcEN1JlECrVG8wjij4H+51EkDkoRrqtl3UPPF9vLIWc04NU4Vn6FcL62RznK7gOA7zH9Muw3fK8OJ5x9ox3ZEpeqh+tsIChF7Mlk+DJMXdeBCl/9hIBkUWYD0jl7+uDc5DYHd8eKxrhMzk4PRjzrOX2rPjX7PzS6kkAgEJze37isCbp5AYqw9Wm0zUZRp0v+EeWK9GDIWaRNSmOrMm4xWVa6CWwhyHlRqhnOe/4qzwVPs5HumAYjLsmr0NBNMJC6vX2qJaOj3Z43M+/XgVGAzkLkPbKPO4aL10Bgx9LBLBnS3ge1nKxm5Nwzo18kLldVKlexkETrCKbRpHrQhhjRMGERMHOB2bH0AAd8t3Gq756pYMnMyqUaeeMcymTrJHEvTx5JMCAge+DQMEQ4+pKB6RmSLNEJ4V0V5v6fk6+0xR939L/Zbvb37ZkhqP+jI3dAsHM7JrFflWLffvM+KDmjfQ+HBNUPN7ie2yuNSngogYZiTQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR12MB5400.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(26005)(66476007)(7696005)(186003)(8936002)(64756008)(6506007)(71200400001)(66556008)(53546011)(54906003)(52536014)(316002)(4326008)(66946007)(8676002)(30864003)(5660300002)(66446008)(86362001)(55016002)(76116006)(38100700002)(110136005)(2906002)(38070700005)(508600001)(9686003)(83380400001)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BP7rdxnHQY1nUEy88D1l/vt9QvsFKYrtxcQU6MNj7N1BmkrNPl6foMFStFef?= =?us-ascii?Q?pe5WFb47pLcPuH1CobY7Fdn966lsBYnUIugqxVHfHCz8FeGL5/yhjwws2bbR?= =?us-ascii?Q?mfSbht9SrKZkwksWHSnCvbnQ7yb6SC8AvL7viiPbYLFjqRyarXRyl7/hd/WH?= =?us-ascii?Q?4aNlhwJhoq2OBnoJ4ETzss37S4ya4vrCoPSfUYTIbiUl5XylX06Eo5BriPm7?= =?us-ascii?Q?kk3B1tJPdTlzMDMCHXFsJnIIn+rmfsiyaSfk5L6lPgiJvdmuRaHaqa48JftH?= =?us-ascii?Q?JyEGtXR+KaBSIz4dti6agdflEej6vh9q/HvE31m50NS17Afyfj3GpBP+VgWy?= =?us-ascii?Q?dBBWJoskrtUz4IEdbdurvKvM/TGu3afjUKe1pji/lhZNwp5aMSRyYjxLvGw+?= =?us-ascii?Q?YI0Br2XIpDLNSxh/JOtzQHE9yl0kulvybB6PKv/vi4GKXWfEZIHxRCbL8PEb?= =?us-ascii?Q?ce3D/2C83T2voNRKFEN6ycAmMZmKGZwECzlpH6ZBPVUgZ6dmfo86q676UFxQ?= =?us-ascii?Q?rKsHAUvFfbF1r60z7yl8NrUq456F/j+I8RG49CwDjxhs7tGXsoJ1h63/Mz5e?= =?us-ascii?Q?1qvOzHcXDvapC+kLER9wbX98gBLw5CbFi3tRlTKUeGBdyVFVfNBXW6lZKwUe?= =?us-ascii?Q?XLauw8vwvh9phwybENs2enRVRTgRplhEpfQezXSmTKggV7FWDdO/r+El5rhE?= =?us-ascii?Q?I0D3x9r7paRhZAWe89GFtofKSz06t6zvqur3GiOlP12Um2d+osFEWENtg2p2?= =?us-ascii?Q?tLWBG/aLese/6cNcIl9o2IDzHm289fCy9A+xVUrISXauOC3imols6Tiqevws?= =?us-ascii?Q?9ZOYkCFrOeCR1lr+wFJLQkyEp/zwV6Q/fK8W1PM5uyczKgR3CxUY8/MVtAJ2?= =?us-ascii?Q?nVBAb67M+3OJGTj34IXX/GYRvEywgO+iRunQKqSauH9Rfcpc+Fd30/4dL7L9?= =?us-ascii?Q?qYe2mYmnz0THl63aaE99ICXQQiTqR3//QLU83WBsBeQ6ZVrKTj2vqiUvn10A?= =?us-ascii?Q?ennipBltEuUMX7wm/kcpbdeBV6Oac0oTdsvIQRTU2sCCEY4509SU0q53eJgJ?= =?us-ascii?Q?w1afRcyGJ3Fnm7eNIQNsXvRn8QmYcapUradnx0tUB9DTQLPV/XCkzeP+enN4?= =?us-ascii?Q?epv6B8L9OKDtNho3l6SRlgw4IuDcMXiV3vTlflF9F4sHCXo76e10SVb7yghR?= =?us-ascii?Q?5RWrFqy6zsf/SXLfJWROk+CVXZLHn7qk+DfACu2+5ohU3OkkvJ+kE8JUS6zU?= =?us-ascii?Q?9XoBUGVjvInEXDhDVavAUjuoxTJoV0qtcZ506B1cdbHxCfZhJ5iPp8aB4y31?= =?us-ascii?Q?AYdInFBAzPUrW+4Xy3Py595o?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR12MB5400.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18641699-8594-4939-6b7f-08d98d4b56ef X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 06:41:36.8886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ih9AUjReUUHiyDNY1Rozf30PbvXiKRittmTxEuW0NX2Yd6d5nrB/C6W4lPkXno8Zr1V9ChN22DrBcEm8DbIu0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR12MB5445 Subject: Re: [dpdk-dev] [PATCH v3 1/5] ethdev: introduce configurable flexible item X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Slava, > -----Original Message----- > From: dev On Behalf Of Viacheslav Ovsiienko > Sent: Monday, October 11, 2021 9:15 PM > Subject: [dpdk-dev] [PATCH v3 1/5] ethdev: introduce configurable flexibl= e item >=20 > 1. Introduction and Retrospective >=20 > Nowadays the networks are evolving fast and wide, the network structures = are getting more and more > complicated, the new application areas are emerging. To address these cha= llenges the new network > protocols are continuously being developed, considered by technical commu= nities, adopted by industry > and, eventually implemented in hardware and software. The DPDK framework = follows the common > trends and if we bother to glance at the RTE Flow API header we see the m= ultiple new items were > introduced during the last years since the initial release. >=20 > The new protocol adoption and implementation process is not straightforwa= rd and takes time, the new > protocol passes development, consideration, adoption, and implementation = phases. The industry tries to > mitigate and address the forthcoming network protocols, for example, many= hardware vendors are > implementing flexible and configurable network protocol parsers. As DPDK = developers, could we > anticipate the near future in the same fashion and introduce the similar = flexibility in RTE Flow API? >=20 > Let's check what we already have merged in our project, and we see the ni= ce raw item > (rte_flow_item_raw). At the first glance, it looks superior and we can tr= y to implement a flow matching on > the header of some relatively new tunnel protocol, say on the GENEVE head= er with variable length > options. And, under further consideration, we run into the raw item > limitations: >=20 > - only fixed size network header can be represented > - the entire network header pattern of fixed format > (header field offsets are fixed) must be provided > - the search for patterns is not robust (the wrong matches > might be triggered), and actually is not supported > by existing PMDs > - no explicitly specified relations with preceding > and following items > - no tunnel hint support >=20 > As the result, implementing the support for tunnel protocols like aforeme= ntioned GENEVE with variable > extra protocol option with flow raw item becomes very complicated and wou= ld require multiple flows and > multiple raw items chained in the same flow (by the way, there is no supp= ort found for chained raw items > in implemented drivers). >=20 > This RFC introduces the dedicated flex item (rte_flow_item_flex) to handl= e matches with existing and new > network protocol headers in a unified fashion. >=20 > 2. Flex Item Life Cycle >=20 > Let's assume there are the requirements to support the new network protoc= ol with RTE Flows. What is > given within protocol > specification: >=20 > - header format > - header length, (can be variable, depending on options) > - potential presence of extra options following or included > in the header the header > - the relations with preceding protocols. For example, > the GENEVE follows UDP, eCPRI can follow either UDP > or L2 header > - the relations with following protocols. For example, > the next layer after tunnel header can be L2 or L3 > - whether the new protocol is a tunnel and the header > is a splitting point between outer and inner layers >=20 > The supposed way to operate with flex item: >=20 > - application defines the header structures according to > protocol specification >=20 > - application calls rte_flow_flex_item_create() with desired > configuration according to the protocol specification, it > creates the flex item object over specified ethernet device > and prepares PMD and underlying hardware to handle flex > item. On item creation call PMD backing the specified > ethernet device returns the opaque handle identifying > the object has been created >=20 > - application uses the rte_flow_item_flex with obtained handle > in the flows, the values/masks to match with fields in the > header are specified in the flex item per flow as for regular > items (except that pattern buffer combines all fields) >=20 > - flows with flex items match with packets in a regular fashion, > the values and masks for the new protocol header match are > taken from the flex items in the flows >=20 > - application destroys flows with flex items >=20 > - application calls rte_flow_flex_item_release() as part of > ethernet device API and destroys the flex item object in > PMD and releases the engaged hardware resources >=20 > 3. Flex Item Structure >=20 > The flex item structure is intended to be used as part of the flow patter= n like regular RTE flow items and > provides the mask and value to match with fields of the protocol item was= configured for. >=20 > struct rte_flow_item_flex { > void *handle; > uint32_t length; > const uint8_t* pattern; > }; >=20 > The handle is some opaque object maintained on per device basis by underl= ying driver. >=20 > The protocol header fields are considered as bit fields, all offsets and = widths are expressed in bits. The > pattern is the buffer containing the bit concatenation of all the fields = presented at item configuration time, > in the same order and same amount. If byte boundary alignment is needed a= n application can use a > dummy type field, this is just some kind of gap filler. >=20 > The length field specifies the pattern buffer length in bytes and is need= ed to allow rte_flow_copy() > operations. The approach of multiple pattern pointers and lengths (per fi= eld) was considered and found > clumsy - it seems to be much suitable for the application to maintain the= single structure within the single > pattern buffer. >=20 > 4. Flex Item Configuration >=20 > The flex item configuration consists of the following parts: >=20 > - header field descriptors: > - next header > - next protocol > - sample to match > - input link descriptors > - output link descriptors >=20 > The field descriptors tell the driver and hardware what data should be ex= tracted from the packet and then > control the packet handling in the flow engine. Besides this, sample fiel= ds can be presented to match with > patterns in the flows. Each field is a bit pattern. > It has width, offset from the header beginning, mode of offset calculatio= n, and offset related parameters. >=20 > The next header field is special, no data are actually taken from the pac= ket, but its offset is used as a > pointer to the next header in the packet, in other words the next header = offset specifies the size of the > header being parsed by flex item. >=20 > There is one more special field - next protocol, it specifies where the n= ext protocol identifier is contained > and packet data sampled from this field will be used to determine the nex= t protocol header type to > continue packet parsing. The next protocol field is like eth_type field i= n MAC2, or proto field in IPv4/v6 > headers. >=20 > The sample fields are used to represent the data be sampled from the pack= et and then matched with > established flows. >=20 > There are several methods supposed to calculate field offset in runtime d= epending on configuration and > packet content: >=20 > - FIELD_MODE_FIXED - fixed offset. The bit offset from > header beginning is permanent and defined by field_base > configuration parameter. >=20 > - FIELD_MODE_OFFSET - the field bit offset is extracted > from other header field (indirect offset field). The > resulting field offset to match is calculated from as: >=20 > field_base + (*offset_base & offset_mask) << offset_shift >=20 > This mode is useful to sample some extra options following > the main header with field containing main header length. > Also, this mode can be used to calculate offset to the > next protocol header, for example - IPv4 header contains > the 4-bit field with IPv4 header length expressed in dwords. > One more example - this mode would allow us to skip GENEVE > header variable length options. >=20 > - FIELD_MODE_BITMASK - the field bit offset is extracted > from other header field (indirect offset field), the latter > is considered as bitmask containing some number of one bits, > the resulting field offset to match is calculated as: >=20 > field_base + bitcount(*offset_base & offset_mask) << offset_shift >=20 > This mode would be useful to skip the GTP header and its > extra options with specified flags. >=20 > - FIELD_MODE_DUMMY - dummy field, optionally used for byte > boundary alignment in pattern. Pattern mask and data are > ignored in the match. All configuration parameters besides > field size and offset are ignored. >=20 > Note: "*" - means the indirect field offset is calculated > and actual data are extracted from the packet by this > offset (like data are fetched by pointer *p from memory). >=20 > The offset mode list can be extended by vendors according to hardware sup= ported options. >=20 > The input link configuration section tells the driver after what protocol= s and at what conditions the flex > item can follow. > Input link specified the preceding header pattern, for example for GENEVE= it can be UDP item specifying > match on destination port with value 6081. The flex item can follow multi= ple header types and multiple > input links should be specified. At flow creation time the item with one = of the input link types should > precede the flex item and driver will select the correct flex item settin= gs, depending on the actual flow > pattern. >=20 > The output link configuration section tells the driver how to continue pa= cket parsing after the flex item > protocol. > If multiple protocols can follow the flex item header the flex item shoul= d contain the field with the next > protocol identifier and the parsing will be continued depending on the da= ta contained in this field in the > actual packet. >=20 > The flex item fields can participate in RSS hash calculation, the dedicat= ed flag is present in the field > description to specify what fields should be provided for hashing. >=20 > 5. Flex Item Chaining >=20 > If there are multiple protocols supposed to be supported with flex items = in chained fashion - two or more > flex items within the same flow and these ones might be neighbors in the = pattern, it means the flex items > are mutual referencing. In this case, the item that occurred first shoul= d be created with empty output link > list or with the list including existing items, and then the second flex = item should be created referencing the > first flex item as input arc, drivers should adjust the item confgiuratio= n. >=20 > Also, the hardware resources used by flex items to handle the packet can = be limited. If there are multiple > flex items that are supposed to be used within the same flow it would be = nice to provide some hint for the > driver that these two or more flex items are intended for simultaneous us= age. > The fields of items should be assigned with hint indices and these indice= s from two or more flex items > supposed to be provided within the same flow should be the same as well. = In other words, the field hint > index specifies the group of fields that can be matched simultaneously wi= thin a single flow. If hint indices > are specified, the driver will try to engage not overlapping hardware res= ources and provide independent > handling of the field groups with unique indices. If the hint index is ze= ro the driver assigns resources on its > own. >=20 > 6. Example of New Protocol Handling >=20 > Let's suppose we have the requirements to handle the new tunnel protocol = that follows UDP header with > destination port 0xFADE and is followed by MAC header. Let the new protoc= ol header format be like this: >=20 > struct new_protocol_header { > rte_be32 header_length; /* length in dwords, including options */ > rte_be32 specific0; /* some protocol data, no intention */ > rte_be32 specific1; /* to match in flows on these fields */ > rte_be32 crucial; /* data of interest, match is needed */ > rte_be32 options[0]; /* optional protocol data, variable length */ > }; >=20 > The supposed flex item configuration: >=20 > struct rte_flow_item_flex_field field0 =3D { > .field_mode =3D FIELD_MODE_DUMMY, /* Affects match pattern only */ > .field_size =3D 96, /* three dwords from the beginning= */ > }; > struct rte_flow_item_flex_field field1 =3D { > .field_mode =3D FIELD_MODE_FIXED, > .field_size =3D 32, /* Field size is one dword */ > .field_base =3D 96, /* Skip three dwords from the beginning */ > }; > struct rte_flow_item_udp spec0 =3D { > .hdr =3D { > .dst_port =3D RTE_BE16(0xFADE), > } > }; > struct rte_flow_item_udp mask0 =3D { > .hdr =3D { > .dst_port =3D RTE_BE16(0xFFFF), > } > }; > struct rte_flow_item_flex_link link0 =3D { > .item =3D { > .type =3D RTE_FLOW_ITEM_TYPE_UDP, > .spec =3D &spec0, > .mask =3D &mask0, > }; >=20 > struct rte_flow_item_flex_conf conf =3D { > .next_header =3D { > .tunnel =3D FLEX_TUNNEL_MODE_SINGLE, > .field_mode =3D FIELD_MODE_OFFSET, > .field_base =3D 0, > .offset_base =3D 0, > .offset_mask =3D 0xFFFFFFFF, > .offset_shift =3D 2 /* Expressed in dwords, shift left by 2 */ > }, > .sample =3D { > &field0, > &field1, > }, > .nb_samples =3D 2, > .input_link[0] =3D &link0, > .nb_inputs =3D 1 > }; >=20 > Let's suppose we have created the flex item successfully, and PMD returne= d the handle 0x123456789A. > We can use the following item pattern to match the crucial field in the p= acket with value 0x00112233: >=20 > struct new_protocol_header spec_pattern =3D > { > .crucial =3D RTE_BE32(0x00112233), > }; > struct new_protocol_header mask_pattern =3D > { > .crucial =3D RTE_BE32(0xFFFFFFFF), > }; > struct rte_flow_item_flex spec_flex =3D { > .handle =3D 0x123456789A > .length =3D sizeiof(struct new_protocol_header), > .pattern =3D &spec_pattern, > }; > struct rte_flow_item_flex mask_flex =3D { > .length =3D sizeof(struct new_protocol_header), > .pattern =3D &mask_pattern, > }; > struct rte_flow_item item_to_match =3D { > .type =3D RTE_FLOW_ITEM_TYPE_FLEX, > .spec =3D &spec_flex, > .mask =3D &mask_flex, > }; >=20 > Signed-off-by: Viacheslav Ovsiienko > --- Acked-by: Ori Kam Thanks, Ori