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 05A4AA00C2; Tue, 8 Mar 2022 08:48:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 93BA24068B; Tue, 8 Mar 2022 08:48:46 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 7DCFC40041 for ; Tue, 8 Mar 2022 08:48:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646725725; x=1678261725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6uF9KKeNijNO8x52gO1lmY8/mCn8SxHfbFWhPvZyEiI=; b=XhDv34t9YOwDE4gz0aitxdEfZ+nuXn6/4zsvdMlY5yjsLlm0UmCxlSjL RtCDpmHPwIU9LEwJJms154C4rNKNRy0KYh2kfc5YTLIkrt+cHSY8GMB1R Snj/FN9sxsp3NWrHlmhTNXnH7CWjoafVuRry0mwMbxzDe+RBKijGgraj8 0yz2woujahgUNY2nPi4AMBDe7yo7tj3W3WyKCVesvQyuzq3c1jj+JAEqV EPXBdKVjxPYXmK9YEd2ABRS2jknf6BUDwklFSeeb//bR2CJCufARuf++Z M9QZiB5C9T5e9G85DcY7KOyEho7P0OFPlbtSP9tJoXI2LkG7LSCwzL58A Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10279"; a="315335142" X-IronPort-AV: E=Sophos;i="5.90,163,1643702400"; d="scan'208";a="315335142" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2022 23:48:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,163,1643702400"; d="scan'208";a="495364783" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga003.jf.intel.com with ESMTP; 07 Mar 2022 23:48:44 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Mar 2022 23:48:43 -0800 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Mar 2022 23:48:43 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21 via Frontend Transport; Mon, 7 Mar 2022 23:48:43 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.21; Mon, 7 Mar 2022 23:48:42 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jw8IFTL2KKZtamLJIW5JE3SsTYHNIMqxQlv1xDYvQiOydkhaVfdauJSLHBKhp3vsiyoUUGYkoO5nHc11+uV+BKmvPi5jUCziSlRtiexBnRhL+APnIk+Ixi8OJRWdBgIHFppuG3rkleSqP55JpIEfYb/UIshA4JuDEWWdEXwgwffsvMQHuS1PK97fwQU4i3zc7P4r9vUtbegzGjac4Pv+Z9nJq2XVnYhCh5/wo0AqoZENcHACIcfSU9IvCYZz3obh36WEkR9Kvo8qerCbNlGYyJe7OKKstQlMWlgODHoPMyK++QifL5BSknA32UtCiblAQwEKi1GIakJzpsMRBaMRlQ== 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=U3TXxhWAxAJ9sH0z8sQRemMzhGYsrSABQ1qIgrN6Asg=; b=CLElCddkLva4/vvDQ7P0OBd+n3gPPI01Oz/I8sMUxLM8nMzpvswstuiGAINLs0DdFeim5JvHUq8qYR0jSJqUnCHLTzBpVe3Ffl1YQ+hDR0x/Va8f4j9kfwQJXSeanaNSFBKTUxYAhufQ6aRmbHpBrY9w92HvX5ssEFhyl+1dJ+9zlLA3Y1q81Tx4N7Y/N99QXvuq2H/f1CsdOF/w5ZI54/zTiEmey9WNGdV5xzOLf0dqXtno8+E71O4VDj1SgMAs7jf/JPvQEP8z6b3dcSuSJ5hz4uBkPk0brWWgGIqnFpMXpuFA2nyTPNstDhhz3QMM7h4gVgXw3pg7b8pEkEbBbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from BN9PR11MB5513.namprd11.prod.outlook.com (2603:10b6:408:102::11) by SJ0PR11MB4895.namprd11.prod.outlook.com (2603:10b6:a03:2de::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14; Tue, 8 Mar 2022 07:48:37 +0000 Received: from BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::7067:8016:bef2:5c88]) by BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::7067:8016:bef2:5c88%6]) with mapi id 15.20.5038.026; Tue, 8 Mar 2022 07:48:37 +0000 From: "Ding, Xuan" To: Thomas Monjalon CC: "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "viacheslavo@nvidia.com" , "Zhang, Qi Z" , "Yu, Ping" , "Wang, YuanX" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" , "mb@smartsharesystems.com" , Stephen Hemminger Subject: RE: [RFC] ethdev: introduce protocol type based header split Thread-Topic: [RFC] ethdev: introduce protocol type based header split Thread-Index: AQHYLsRgHhiLy7U9DkSe/bxhM3fGdKytWzqAgAeunHA= Date: Tue, 8 Mar 2022 07:48:37 +0000 Message-ID: References: <20220303060136.36427-1-xuan.ding@intel.com> <5016713.VdNmn5OnKV@thomas> In-Reply-To: <5016713.VdNmn5OnKV@thomas> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ce8a09c-6ebe-468b-00ac-08da00d80e37 x-ms-traffictypediagnostic: SJ0PR11MB4895:EE_ x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gYu+/HaL55bYO4ch9OpmR6YEoiUh/GVexRXEu3fdc4cOnAMEaqT7cEHUGwDMlle2IAL9wJnZJkwOq5CugBnE4kkOyLPPjqyGuyVsE6pVoaUvXaeCvSbwESAYF9pvcz42EDodLCxE5aS4YFsRYE4KrXyfAI2HRPw0DRKoaN1mKyfoR+JbkAzjdDEwcRU+P9YGXwTxVr0Hax4P5QRigh7wk8c8BV0rl4z8bTQIAz60PqJwtyL6VWxnYJAC5MA1I/zdUHkGGSSpN5KyS9SEvlgP5Su+2y3CUbnTp24C2E0L4KLy/9et/zb97vK+WISQA30w+p9bRJPRXbOinXTZOOOVbrusZzawVEZYg0tWSEmgfT5rWZnLnxZY+y46c0w3Htn4A8Skk9zhuNWho0zr/Pc4bL4zlTf8LqSD4PZUFe7nH5r5N8I+rpnvim44qgNsntZ5OA009c9vMJD+rbxXMbyhpjQJsFsI1Ddnmh7SdPRq/Y2srHnIMh6XYlETxkmx+rnmqhr127ZMYloyPGirmuPgj6k2NqHDU6lJBi8I42QqodS5Lj99hClqGlrl70lFTK1xD7w5qAdtk2+vKcYu8R/2YQK/hQZdjBmJTZqndzIfXJFFeKLnP/2Fd5HQk8k6Swi1PkhY8jvOTfj0O4s4qtsIbR7ppvLRCMNXCJlTkxwzuC5RUmaCQ23U8d6fpkZAhl+k4gdPgL31Ilvy1R70b+Dvgg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR11MB5513.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(508600001)(26005)(55016003)(6916009)(186003)(9686003)(6506007)(7696005)(71200400001)(54906003)(86362001)(53546011)(38070700005)(122000001)(38100700002)(83380400001)(316002)(82960400001)(76116006)(66556008)(66946007)(4326008)(66476007)(64756008)(8936002)(8676002)(66446008)(52536014)(2906002)(5660300002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?ajB5bUJlOVl3V2RUaHlac21KRFU4UWF5RGp5VkF2cEJ3N3JZR09Maml2?= =?iso-2022-jp?B?UDg2eFZaZEdHQ1RkQXVHc1A1VGZTWEpka2Y0VG5HYWEyaEE5eUVXUGM0?= =?iso-2022-jp?B?WXE4TEVKZFgyNGd3RUJxZDVweWdpQVZRdE9CNjhWWFF3dHo3N1dmZ2ND?= =?iso-2022-jp?B?SnRGbk9zUUhuZXFkYTNMV000Vlp5eUlCT25hakZQbHpSMEtXSW10bXRS?= =?iso-2022-jp?B?KzhLcTIwbEp1TTltR3R3OVlkR2paSkM3UkRIRUlDSHF6eDhEY3hBaFF4?= =?iso-2022-jp?B?RmI5RlZzTDBqQjFFMi9ma2NDTTVTUFJFenJ5TG5wTytlMTFSSzdpU0FP?= =?iso-2022-jp?B?SG95R3pMRGtaT2cyUWhtVG9VU1RBaVJVMU5QRmNxR0hqTmRHUGJKeWNU?= =?iso-2022-jp?B?S2c3UGZoaXRMZ2ppTnhTd3lWUXlaNjJRamtQVmMvL3lRamJXUHBwb2RJ?= =?iso-2022-jp?B?ME1kOXJvWHdYd1hOU3RNcXRwRmNiUTlReUxuc0ozNklTenV6OGY1WVNy?= =?iso-2022-jp?B?Szl2d3Q5SThkUjNRNlZXajRjNDhtZUY3NjlnS1ZmRkp5Zm80bDArVUlh?= =?iso-2022-jp?B?WnhsbzkreWVBSlZzZnVYZTNFb0Fyb2hKd2RXN25DWi9aYksrZEpuRy93?= =?iso-2022-jp?B?QUJ2aFJpeXl1S3QydW1FQ1dJTDJJcjJZb0czMUNpcEd0WkVtV1pYWWgy?= =?iso-2022-jp?B?b2p0ZEo5anZsalNkbWIxRHFFQ3NDblE2U3ZPNmJUalNVQjROeUxFSUw2?= =?iso-2022-jp?B?V2ZjSHZiZUtIcnQ0ZGJ0RWFFWURvNThJZ05nWTlsQjJYU0hOaEM2YVZ1?= =?iso-2022-jp?B?ZUpkc3FWVWNSMjdMU1lYY0I3SnlaVWY1YWEycVBrS1JGTTRTcElIOXl6?= =?iso-2022-jp?B?UjBkRlhUcCtaYXF5OU9DK01renZLME5UVWxxTWw0V3ZJZnU4K1ZJZUYy?= =?iso-2022-jp?B?ZUxUUEZaZ1RZVDVBZGVGMjZOS0ljYjVYSk9yd3hBNS9BRGxtSkhEaEJS?= =?iso-2022-jp?B?b2Z4b2ZiNVFZd1hEbEZkckZsNU01aEdjL1VFL0tBMlFzQ1E1YnlvRGsy?= =?iso-2022-jp?B?dytFMExYeWpkRW5BWThESnVzOG9tdjBuY1VhQVFSd3Y1Zm1jYnAya0dh?= =?iso-2022-jp?B?R21PaVYrd2Q2MUxlUEY1cEZYdFFQWllESEhhUWtaVDNFYW1RYmx1MUVY?= =?iso-2022-jp?B?QXVSZjFGb2hXV1RlMzJzWXBJMG45WDY3Mm5Md3lIWnFYTmdqNjVZYk93?= =?iso-2022-jp?B?dExsZ3lWNFFUeW41NHgxUlk1YWNKQ2Nodkp6bXhEMUtHbkZIUXJqbEVD?= =?iso-2022-jp?B?YTRMYlF6NmphVFlsb0ZaWEc3aGNCOG1pYnJXWXBUalc2bjNqSFNLVmlr?= =?iso-2022-jp?B?dWpQdGRVS1NUN0NtdFRuUm9palUrR1BrdVpZbmVtRXR6cHlNUWN3elZF?= =?iso-2022-jp?B?K0ZKYVdER1BtZ2xYYWZWNndSaFhWeW9EdEUvL2c0QW1tTFBicDJZa2pU?= =?iso-2022-jp?B?VkY0Qk9OdVJ1OG1ScXpYSkJZTWpNK3ZSdWpNbm5rZHdPTUVOYytSdGNJ?= =?iso-2022-jp?B?S1MwOUg5dWd1OTVyU3Q5MGt2UmwySkVPSnM5UnV2aHFZeHRHb2J2MEM1?= =?iso-2022-jp?B?K2dTVnpyMjlLM21rM09JalNVZ3UyM1U1TVZveWRCU3BZcVQ4TFgyT1RV?= =?iso-2022-jp?B?Tm9KaER5TE84elJSMG9nRGFEUG5VY0N1cFZVNEViV3BOdEUvQVVXRnU2?= =?iso-2022-jp?B?eWxoNWUwMnZENFJYZW9Tdks1d3A3RWs5WGQzOWNGVVNKREs1N241Q2Rs?= =?iso-2022-jp?B?dEM2R21ZbmNMN1JxMTAzbUI5ODY2NGZNcXVoTzk5TVY1cll6K3pYVEg3?= =?iso-2022-jp?B?TnJ4ZWEvV2g2Z0RHY1ZyQStVaWN3encwUmwvV1I4WWxlVnNVa0w4MzZG?= =?iso-2022-jp?B?VWJyM2gxelNJV2I3eTFSTld1M0VpbkNGOUlLMXZZNVhkb2pQUWQ1V0dq?= =?iso-2022-jp?B?Y2dMNzFPL3pCTlk3RHVJZU5WbXpaVkxwdVJLYitOSWF2MDNTMnJEUThX?= =?iso-2022-jp?B?aUR4ZldLUFZwQUQreDRtcVdaMmlOQytsODJrNmtMVVlidmdaTGpkTHZC?= =?iso-2022-jp?B?VnZmQlNQQWhWZXlkK1hrYUllWStDeVlxbUZVMkorejhrdUt3eXJuOTZY?= =?iso-2022-jp?B?dGtjaDBwRXhGeWJNb3psTS8vbWpkR2xwc3ZHWnlYMElsMzNpbjhzMGN4?= =?iso-2022-jp?B?N1dnRmNrN0cwNGtqbjJ1N3pKemcrbUcyNE5MMlBLalptQWlyaGFIRDli?= =?iso-2022-jp?B?MXl3V3hFaEZTWjlLUVpLcGFVQWY5YTZqdlE9PQ==?= Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5513.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ce8a09c-6ebe-468b-00ac-08da00d80e37 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2022 07:48:37.5568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Fa58qTkBJzmNZYLFKZH5vdpTrbdbd3uh8viTVreT808/vi2UHNvsZcfSexVhTj/WX2UZFN+IubyH2hLAhRpMHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4895 X-OriginatorOrg: intel.com 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 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon > Sent: 2022=1B$BG/=1B(B3=1B$B7n=1B(B3=1B$BF|=1B(B 16:55 > To: Ding, Xuan > Cc: Yigit, Ferruh ; andrew.rybchenko@oktetlabs.ru= ; > dev@dpdk.org; viacheslavo@nvidia.com; Zhang, Qi Z ; > Yu, Ping ; Ding, Xuan ; Wang, > YuanX ; ajit.khaparde@broadcom.com; > jerinj@marvell.com > Subject: Re: [RFC] ethdev: introduce protocol type based header split >=20 > 03/03/2022 07:01, xuan.ding@intel.com: > > From: Xuan Ding > > > > Header split consists of splitting a received packet into two separate > > regions based on the packet content. Splitting is usually between the > > packet header that can be posted to a dedicated buffer and the packet > > payload that can be posted to a different buffer. This kind of > > splitting is useful in some use cases, such as GPU. GPU can directly > > process the payload part and improve the performance significantly. > > > > Currently, Rx buffer split supports length and offset based packet spli= t. > > This is not suitable for some NICs that do split based on protocol type= s. > > Tunneling makes the conversion from offset to protocol inaccurate. > > > > This patch extends the current buffer split to support protocol based > > header split. A new proto field is introduced in the > > rte_eth_rxseg_split structure reserved field to specify header split ty= pe. > > > > With Rx offload flag RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and > > protocol type configured, PMD will split the ingress packets into two > > separate regions. Currently, L2/L3/L4 level header split is supported. > > > > Signed-off-by: Xuan Ding > > Signed-off-by: Yuan Wang > > --- > > lib/ethdev/rte_ethdev.c | 2 +- > > lib/ethdev/rte_ethdev.h | 17 ++++++++++++++++- > > 2 files changed, 17 insertions(+), 2 deletions(-) > > > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index > > 70c850a2f1..d37c8f9d7e 100644 > > --- a/lib/ethdev/rte_ethdev.c > > +++ b/lib/ethdev/rte_ethdev.c > > @@ -1784,7 +1784,7 @@ rte_eth_rx_queue_setup(uint16_t port_id, uint16_t > rx_queue_id, > > &dev_info); > > if (ret !=3D 0) > > return ret; > > - } else { > > + } else if (!(rx_conf->offloads & > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT)) > > +{ > > RTE_ETHDEV_LOG(ERR, "No Rx segmentation offload > configured\n"); > > return -EINVAL; > > } > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index > > c2d1f9a972..6743648c22 100644 > > --- a/lib/ethdev/rte_ethdev.h > > +++ b/lib/ethdev/rte_ethdev.h > > @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split { > > struct rte_mempool *mp; /**< Memory pool to allocate segment from. > */ > > uint16_t length; /**< Segment data length, configures split point. */ > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer.= */ > > - uint32_t reserved; /**< Reserved field. */ > > + uint16_t proto; >=20 > If it is not explicitly documented, it cannot be accepted. Thanks for your suggestion. The documentation will be enriched in next vers= ion. Let me give a brief introduction here. >=20 > What happens if we have a non-0 proto and length/offset defined? =20 As Morten said, the proto field is exclude from the length field here. For buffer split, the length/offset is needed. For header split, the proto is needed. As for offset field in header split, by default it is zero, it can also be configured to decide the beginning of mbuf data buffer. In conclusion, non-0 proto indicates PMDs can do header split.=20 Length defines PMDs can do buffer split. >=20 > > + uint16_t reserved; /**< Reserved field. */ > > }; > [...] > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this structure may change without prior notice. >=20 > This is not a structure. >=20 > > + * This enum indicates the header split protocol type */ enum > > +rte_eth_rx_header_split_protocol_type { > > + RTE_ETH_RX_HEADER_SPLIT_DEFAULT =3D 0, > > + RTE_ETH_RX_HEADER_SPLIT_INNER_L2, > > + RTE_ETH_RX_HEADER_SPLIT_OUTER_L2, > > + RTE_ETH_RX_HEADER_SPLIT_IP, > > + RTE_ETH_RX_HEADER_SPLIT_TCP_UDP, > > + RTE_ETH_RX_HEADER_SPLIT_SCTP > > +}; >=20 > Lack of documentation. > Where the split should happen? before or after the header?=20 When header split is configured, the split happens at the boundary of heade= r and payload. So, after the header, before payload. > What means DEFAULT? =20 DEFAULT means no header split protocol type was defined. As this time, even header split offload is configured in Rx queue, the PMD won't do header split. Actually, using NONE is more accurate. > What means IP, TCP_UDP and SCTP? Is it inner or outer? Since header split happens after the header, so the IP/TCP/UDP/SCTP defines the header type. When take inner and outer into consideration, The definition should be refi= ned here. For example: rte_eth_rx_header_split_protocol_type { RTE_ETH_RX_HEADER_SPLIT_NONE =3D 0, RTE_ETH_RX_HEADER_SPLIT_MAC, RTE_ETH_RX_HEADER_SPLIT_IPV4, RTE_ETH_RX_HEADER_SPLIT_IPV6, RTE_ETH_RX_HEADER_SPLIT_L3, RTE_ETH_RX_HEADER_SPLIT_TCP, RTE_ETH_RX_HEADER_SPLIT_UDP, RTE_ETH_RX_HEADER_SPLIT_SCTP, RTE_ETH_RX_HEADER_SPLIT_L4, RTE_ETH_RX_HEADER_SPLIT_INNER_MAC, RTE_ETH_RX_HEADER_SPLIT_INNER_IPV4, RTE_ETH_RX_HEADER_SPLIT_INNER_IPV6, RTE_ETH_RX_HEADER_SPLIT_INNER_L3, RTE_ETH_RX_HEADER_SPLIT_INNER_TCP, RTE_ETH_RX_HEADER_SPLIT_INNER_UDP, RTE_ETH_RX_HEADER_SPLIT_INNER_SCTP, RTE_ETH_RX_HEADER_SPLIT_INNER_L4, }; Considering some NICs don=1B$B!G=1B(Bt distinguish the L2/L3/L4 in header s= plit, a separate L2/L3/L4 is also defined. Thanks, Xuan >=20