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 94773A0C47; Tue, 12 Oct 2021 13:42:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1EC624113A; Tue, 12 Oct 2021 13:42:20 +0200 (CEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2086.outbound.protection.outlook.com [40.107.243.86]) by mails.dpdk.org (Postfix) with ESMTP id 2A27D41136 for ; Tue, 12 Oct 2021 13:42:18 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hb2Jb8G7gWt6D9nJOn9bSEoqk4Hr2EWkj/1G+xDfZPTFxQZ+vHMTdtecnliHzhEcnnuKiRDFGCVTGi7ugmQHIGlFN0ikfpxyomz7upXl6pSjDiaI9kHngwp9+JhlV47sI7BHP4zxxhaJqPGvtwzCttqdL0/G66Op4qfBd+uTf3cJtYHqc3es+DFoq1DZSz2aw1C2kW3tu0HD8GZMoWaJbBNIROinLkOMNdSMBEcjfd0nFBH422eqkt1i4Q3uUEiISc5nEenZRgNfrKSG/Mf7S2TnhVnpCjw0sLkmZF+t0hMNf3mxyPCumY40ABRAJ1d78JaNejhkUQqZLFn2+LRhZA== 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=16tYUqn23QPQZFpJNBfeZVG66r7XlBlSgnJC0LrDQCU=; b=A1OYFSGRNyQJGtYXSyEgXheq7KOD/fJFlPaPTbN0MNvbx/F2kg5vbeydyHmNbnhH0usE+QXpGBoanrQE0ijXcdHazteoR1dtYQvGwOLa8/SWCxclCxKMTvdMvZomsbUXq/TlFgavSJzmPST8GDcaI3+n5c9bsbc3G7ZaN1oBU1pyA8zhhUfp1NrFZNWQombn4MC4w9+lrAZT7T/kCuSS7SXR5Qvo6w6LhcPC+HbTDpIWwVwSCSoFdenLOAgDJfVbRT5VKKXmIJP5AhXSC4uwBj0I2AavRWOmo7lmfe1ckr1FdSvgTe1vBneHhtKXJluY0l1Gg1W+yNFad+OFpvSXGA== 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=16tYUqn23QPQZFpJNBfeZVG66r7XlBlSgnJC0LrDQCU=; b=MtVNVbILB15msmlvxOXUOPXMdteW6bdTU1HLe9D/Bf7cXxdxdvDrgL54epNHG/Bt4iRzTMstB+h9U2Gol1lQuCHBvG9kf01q7dyCvFiD0/+V+75prwWwR/Jh3x41uL2dJYIaT+OWe6c6vE3AXEoKqUQImMZ2ncJ2Rv4yQ+dxod/ps9rL69N9x8qo7SZS5uHVKAGqwydCf+IvTeMYeHgUeAKDNuqnKN6sYSRXm0f++b/L1ZIYDwoEXtam9wbfCSjrL4xjPvPm/Na4Go8RvKz6bTBPIKyVrPPmU+QYsZlwNbbleKlthiUaJriVnGTmli4XE7VcwnjKrgaJGRcU+ETU1w== Received: from DM8PR12MB5400.namprd12.prod.outlook.com (2603:10b6:8:3b::12) by DM6PR12MB5520.namprd12.prod.outlook.com (2603:10b6:5:208::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14; Tue, 12 Oct 2021 11:42:14 +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 11:42:14 +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 v4 1/5] ethdev: introduce configurable flexible item Thread-Index: AQHXv1zseEidjj/9b0m8dNAeR8yhoKvPPSyw Date: Tue, 12 Oct 2021 11:42:14 +0000 Message-ID: References: <20210922180418.20663-1-viacheslavo@nvidia.com> <20211012113235.24975-1-viacheslavo@nvidia.com> <20211012113235.24975-2-viacheslavo@nvidia.com> In-Reply-To: <20211012113235.24975-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: 05d9d29c-ee9e-466c-9394-08d98d7555f5 x-ms-traffictypediagnostic: DM6PR12MB5520: 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: 9riMrUQmlP0X3V0FsWOP+ABPhdiYK576pamcwur4kYkGqJOBnU5SrqjsRXEGMAQO/uEDCAAg6UkvGi1CmuXFKkOdeUhsjvQl20B86SaOfD5wCHIRyMCpUw/Tlyvt9UMtIwUQmWhLnJWHTqTcRP/bLS0bG5awkzgQVAOVRsWgiZfvhA0urg6TV/RvBPSGLBdZEOJPArBLs236svwg3iWsWXl2bzyauNPRYohGwh4KdlzOT22+iH8VJWseQPhCtmq3vlci6CC6Va3JNgKwML9oSIaI6hzqo41ggSqLv8WnMc0VG38bP6UZ48DcUuB70+l18/7VkKwQqv1OLl2eaoSlMsDHyRt58BEG/r322fkpWZGLd6uFahq+RJaAZWv7JxfUdZRQNCrWOBTBbarVFH7K8/OKIBHFtqiw30WcixAOJ8TqKgWI15EdFIXyfYYm0Y2J6K5SHufEwHH0ZJs8HKnQ7BJxAdFpOE/14XXZrVxFzQIXRQc2PhhuxT2i+NQ8dipeBx3K+eYzr5aMDfme45a26Dzdfb8AZKAbkFte5wavZh4coVttKqf7aA3NytrCsLQEbfsLm6GRjDymI2WRZ4SymOMK3Ps9GShoY0pvnDCsturScHd6eh209kC3/jmf68ymh566RcmAiPdLOXgx7s6wENXfACqwDamnL1+cOAcSWxuwu46eUpqlUPikQNkNsa1kgEKqsU43beMkjbeISfujxQ== 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)(55016002)(38070700005)(38100700002)(122000001)(7696005)(4326008)(6506007)(53546011)(9686003)(52536014)(54906003)(508600001)(110136005)(5660300002)(33656002)(316002)(8676002)(76116006)(2906002)(8936002)(66556008)(66476007)(64756008)(66946007)(66446008)(26005)(71200400001)(86362001)(30864003)(83380400001)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?oqNaKMe7R/ZvuCv02uUddxCBAd5Nzm7r+90YLxJc4qSjoyrS776RuePBKJPL?= =?us-ascii?Q?JAO00vuWgVKo4SVFlkkPGRUodVlKxZ6Nx51x02oAj5UZtDk4CvVwkX5t94DH?= =?us-ascii?Q?ksP4XXN/1IM0CIyQg7wddsZCEnYm3fmxqn7JLBOvLrHp+07BCJKTjBb625OI?= =?us-ascii?Q?4Oy09NkspK2HsxycAQ8DzjR76+b0raPxoDvVM6fYWLFkfQ4VFz5DEqPPV4DC?= =?us-ascii?Q?reztmxZQGslSUm4SeYCNHJK0BAZIlb44dKRJrPziz2YAoQrGY3dQrghd2SoY?= =?us-ascii?Q?38c26FWI0nnNvKeVS3rsj8YGQMvZnex6P02Q9RIoR70XSd5L8zWbRd/N6Cge?= =?us-ascii?Q?wrsWJM/N7HuOwVZ/2mI5LppmRJ0b62usRrOIheP9Fwb4Ncp1OunY+D0OPExx?= =?us-ascii?Q?UA4nJcO1rxkel8XMsAd0XpQ3XKnsFBAZ0OXxGaeJhP5Jbm81mB4O9IfPUicl?= =?us-ascii?Q?o0dR2bkodQxnpC4fmH3FB9WYhs5PIaVeolN1xtOedvkrp0mKcYD2/OcNgcNa?= =?us-ascii?Q?8HkgIt9Uyz8/6yB1QegVZM8S7AoERnLjwa3Y+Jl7XbkFa6NMuf6z+LD0n6BV?= =?us-ascii?Q?L0o5vADkxrSkqzAL5Cu+hQAvIEfb+SzWSbaMbXGXSKZDxl12CJISSB+zYw5K?= =?us-ascii?Q?QC9QJEzoMwgI7IVn6E1z69Tn6i+g8cXpoe/YKiowJX03sULADhAMAN/J1fc6?= =?us-ascii?Q?CwFLIS+tRvLb8yYEBf3MDUd9kqos/wSuZNATl8LsQs72pID/2OTXYW6EJ5YS?= =?us-ascii?Q?bckTGBzBFHeKdm/q8UaXePITjxrB62tksZ8jGvYP7yhiMJk/lhY5R+caNkTB?= =?us-ascii?Q?o1S8Q4pLVzW4JE5JXzhPEdx+PApAjdYVka4zM0dGDoYipSCMiwk5hv7vaVch?= =?us-ascii?Q?cjOYNYE9fEpejcO97HoMvPc0OGMohM4YCMW4zaZt9PrugAkjiiqGg3kaC7wK?= =?us-ascii?Q?T340yC8R16J+/gWGbrS9xGjuKGOSp1Mno5P6yL7XKCKDZ4y33pKrkAbb7vac?= =?us-ascii?Q?L2UaQCHpyMUaIcnnBzCInvZ37dGZz7v+2YT382XMpwhno+RshlcwnLFrLnDz?= =?us-ascii?Q?WGixO3kpbCP3AOrqqOSCNB/cm9ejkN20oUXYMCJpTqSL3FG0qk15lTJsAiKW?= =?us-ascii?Q?Aw7WteRzh6OeuJfS6APSScAkiIOIPAHjfCi4dbMJNdlYHs1ANeUH6JH7VJMp?= =?us-ascii?Q?p81lJ0u5RotIZ/CMHvLfyvuyLXZ+O3y2t7PZVSJJLaO/uBoIB6bDFdYaO118?= =?us-ascii?Q?ZBw1YMAtlfYpi+MaB17ENvVIujgj5G9r+tn/3jIU4kkLEmWHm5B5Kdmi/wnm?= =?us-ascii?Q?OzfBnI5cHlRXMrVZOsU+iFfJ?= 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: 05d9d29c-ee9e-466c-9394-08d98d7555f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 11:42:14.1139 (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: ijwBARRilDuGOVgtWoYCTzGVB6CvcTnwv9XJMCnEsgIqxr90v7b+3UsjC4PqaYnlVOYNwBtDrWylOYU/naOwBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB5520 Subject: Re: [dpdk-dev] [PATCH v4 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: Tuesday, October 12, 2021 2:33 PM > Subject: [dpdk-dev] [PATCH v4 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 configuratio= 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