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 A40B9A00C4; Wed, 28 Sep 2022 17:42:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4EBD44113C; Wed, 28 Sep 2022 17:42:24 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 3CADF410FA for ; Wed, 28 Sep 2022 17:42:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664379743; x=1695915743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9y6ELYH3knMw4Wq5ewWnbDA4O7xSRlX24lkxzaLRB8U=; b=TQY1ASmCY8jepSgWvF39kzH90sZd+2/5H0tqSQmV0HE7/ZJ4QBu54zQW nB+cQeL2bQrXO1FOIyloGZ7a2ql7ZBf9a5pUp8qeAf5WOjob77sHP3tJ3 YtbTehkOos8l1NEBvY2hPmT7oY1WfajWDViVN/ZSTyLq6gjRWXGM3HxWU s8UBJ2Jp3m17ELdmes9RzaGbB7sZaBzCfr0QwovlkMN8mhB/qQq3J9lAp 1WxJxIct8FYQ+yq3l9Is9pYUrPNuZiTiwc9tyPQof1tCJkyjNQIfvsHoU csLh+no6EBFSdVwfkFASvWwURHF4d7Zyd9KiX1nhwcZs5JP2oX2vt13Te w==; X-IronPort-AV: E=McAfee;i="6500,9779,10484"; a="284769174" X-IronPort-AV: E=Sophos;i="5.93,352,1654585200"; d="scan'208";a="284769174" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2022 08:42:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10484"; a="621966458" X-IronPort-AV: E=Sophos;i="5.93,352,1654585200"; d="scan'208";a="621966458" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orsmga002.jf.intel.com with ESMTP; 28 Sep 2022 08:42:20 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 28 Sep 2022 08:42:20 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 28 Sep 2022 08:42:20 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Wed, 28 Sep 2022 08:42:19 -0700 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.175) 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.2375.31; Wed, 28 Sep 2022 08:42:19 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oGBmVRH9sZTFD0FVv0nxlOWUhdFSD/gXAeZSqBJRpWbxaFVkF/Jv8Yv7HmWY+cUQ0A+BtA62jr5Ebft3jIkcIMBqXOsqkd1zekX0LKNAXTpshwhajmpw3QBYRbp4l18Ejx6ZKT7Sydniv4lsZVGnd42jZgZQNdQrsmJezaf0ruM7XUey7INWFaOE1iBTgiFSdK0j7FjpNCtuESJVJHuHF1/gAi/uO8boqDHXOQGjGwCFNFglsmsECBndfGHhG49QB7iZ50+SYh8C3TUp3n4BcWQBMQbn9d+OLxpZMTrEyF7DSQQyQjRXfvwPT4zZgmc5Vgk2WxR6KWqjcjTh0GqvaA== 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=Bg06xItSg8S8cHXa3TyL1qpf/bQenIXCO4qYJMBz36k=; b=HxZNHr/e6RNObYNCRocrPBX0pKNiBWdmnidPoq6mlibF8SZ4DxwGIp3MRusK3GSZv2Dn1HhnycV7jyGEl3iyutZ4/RwuBXZzF3jSepuLchAtLZcOHOqRfUhPJv8nGHafsdXztAXF1zmYm9cd2/3cdZTxSogrjYW5ltXXlQ0s0x1jsMaALTRWs3fWLnhqUIfXUj85Uqv8rC/j3pSgVSeDQaQvR0WCblb0E64/I8rCsGevlKISqFdxmIkQrXWBd6SY72awnb3q4uCvITM7ow+8JrOgFocBOdNdqm9aHPlxZS4xcQjBK0DkMmpemV8aoUrc3XEp36H85drzZFMZqhQ1PQ== 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 PH7PR11MB6953.namprd11.prod.outlook.com (2603:10b6:510:204::6) by IA1PR11MB7269.namprd11.prod.outlook.com (2603:10b6:208:42b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.26; Wed, 28 Sep 2022 15:42:12 +0000 Received: from PH7PR11MB6953.namprd11.prod.outlook.com ([fe80::b4ae:1525:a457:6ad6]) by PH7PR11MB6953.namprd11.prod.outlook.com ([fe80::b4ae:1525:a457:6ad6%9]) with mapi id 15.20.5654.020; Wed, 28 Sep 2022 15:42:11 +0000 From: "Wang, YuanX" To: "dev@dpdk.org" , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko CC: "mdr@ashroe.eu" , "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Zhang, Qi Z" , "Yang, Qiming" , "jerinjacobk@gmail.com" , "viacheslavo@nvidia.com" , "stephen@networkplumber.org" , "Ding, Xuan" , "hpothula@marvell.com" , "Tang, Yaqi" Subject: RE: [PATCH v5 2/4] ethdev: introduce protocol hdr based buffer split Thread-Topic: [PATCH v5 2/4] ethdev: introduce protocol hdr based buffer split Thread-Index: AQHY0UtRjCZUBnT6okep+alh8T8fBa301zHQ Date: Wed, 28 Sep 2022 15:42:11 +0000 Message-ID: References: <20220812181552.2908067-1-yuanx.wang@intel.com> <20220926094039.1572741-1-yuanx.wang@intel.com> <20220926094039.1572741-3-yuanx.wang@intel.com> In-Reply-To: <20220926094039.1572741-3-yuanx.wang@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.500.17 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH7PR11MB6953:EE_|IA1PR11MB7269:EE_ x-ms-office365-filtering-correlation-id: 0236f9b8-e627-4c5d-1aae-08daa1680283 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wib10U8QeLcQ36E/VQcMMn5DwHDw7Es0+jCqjVLEfAi1jlfCnhgysww+Pl/vAVVolbgbPRLld/5gt3JHpPn5zmXkgRQ8DMq+J9c9JLxR4WNQSljZYXQyfcF8i61YC8ekVh43LwaVyyyTckMocPoA6OOBcy9osV62XcElFqtInoAf1rE/Yid0AwxIYqxMVzMWLG2CrIxegurPna3OOjpRhuidfHDg5wTnQjxBUiMDkYy61feKo0O7m5S+Our9KQaHM0sg/kwhYqEphbHCLs5wADc9JzNjDFblvUNPGDDqETpTBnPFvm+65zVFxh4QzY63zBJv4gAJKF3FotwATINA+1iCYnN/3M6Vr7jXNfWNqweWCQHQwuf84aQbNAVsdBQTR34JZu9MrwE8bk/LLpVwhCPp25sz+ssg29FLlJvrCnYo4F1wNXBiG58Z5zBG41Xywwzj8H1hLxJC1qjS25tT5Q1SDR0GD//PYhjTfyamCQi+RML9+4+IDxJmtAEFd1k2JX6hMpS3VaQ6Yu3+mEWX3QbVK2ahS1HjmMUEvBmW4INUd9JUbixOBKJpk7woVoInTUspm8cL8/eDvMnqveT6RhW1yG4TP0hu3+tH4LRLqCetcBlD8ZSNeJ2CgJ8leDSjslH06pTTStDUS6SQtOjnSPaNCji7XEEY79Mh2MUnB0RI2Or5KOmtuDyTz5HMAv83hIC4PMjh1MOVbt/lUSUdkwtUdlKwcGN3IHXfFUKKaI3RgMH07t1C/SsF9mTZ62q0K06eJBsiYoMKQK2FwKmL3w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH7PR11MB6953.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(346002)(376002)(39860400002)(136003)(396003)(366004)(451199015)(8936002)(82960400001)(4326008)(8676002)(107886003)(66446008)(7696005)(30864003)(33656002)(41300700001)(66476007)(66556008)(66946007)(64756008)(76116006)(316002)(54906003)(38070700005)(110136005)(2906002)(86362001)(71200400001)(38100700002)(122000001)(478600001)(186003)(83380400001)(52536014)(5660300002)(26005)(9686003)(53546011)(6506007)(55016003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?siogGjrlIRNnn57Y60eI+cKAGUpzuBmwphivtlT9fYS6Gip2laZ36LFKSETY?= =?us-ascii?Q?r0KwkhozlNoJBdp51mNU5UddsljJSrUlSUQP53HDgJ9zn3XwilJsM1oC83OS?= =?us-ascii?Q?Sgi2rYD89jVcxuwR1lXIrilBhs333hVWwkT3NF0wu4Qcfe4BAUyuXUJewixV?= =?us-ascii?Q?Eq16JHT4fhYu0xNCMz+kIprI0730BvyJJ5tvU9wRAt4676k3R8Fdc+Ds0cz3?= =?us-ascii?Q?aCia0zatNo9UwM7ikeaAGTNr2yENnWEW2XdtJ0P3K6Bk4TrLVLnt0T5jvT6r?= =?us-ascii?Q?A6gLUSWErn5t6dubtugmUrWpWuy/GPBoOx4R/RtWRs/SxKwRTdGBQjODZfeD?= =?us-ascii?Q?wyqLLD0LYy60tODuLouWCOGD9XtdFmaKQDlTkagQ+A6R2MugOBlDXqn/Yu5K?= =?us-ascii?Q?5wHDjnP2aTjqego5ILUAuUdPG6R8f1eaAgDa2qdL1+aSDDLYUScPJikH0J9G?= =?us-ascii?Q?cSFhddZfVQJEskaeJRYkARAlZSS5GsxUDVBN44sunYaEUKHc0kWaeAcDiG5l?= =?us-ascii?Q?HngtnVrgIQ6gQiu2BreCandFjzsF+En0J0WM9dVqSfddIWryObYkNvw1ADep?= =?us-ascii?Q?m25vgAUfcstrCnMovXyKKgIEQSTNaFJIB8U6iOkvDU20TIIKKtfro/GPiQLo?= =?us-ascii?Q?tOpQp3e9heVofLnLZVRLaIwLNwlt2NnMzttjYZIeuUK48LA4QBR/wJd9xU/j?= =?us-ascii?Q?xNs7yGptQut4rRI/7YzetD+20LOAGQ6aCaeZV+hJV2g8aTC411cRl5VcUmZV?= =?us-ascii?Q?nPYlZgQu8XzGzRlJl2YbQEEYYSsODm8YIZs1z5FB1rFryJGmwkxZX7VvOPaY?= =?us-ascii?Q?dagdnXg1dgx3kUaPyh3sJv+0+VkcPP3kDtUjxM88PXGhALG+LuUD8l13aAey?= =?us-ascii?Q?+eBD9xHR+debquV+KdrUpSF/+wD3RAp3v77GV2dIUq1btqIT7zesdCRDp0H7?= =?us-ascii?Q?UyCWoO993gKJOhO1LcyBAORAD48FvrC8CZre2cdgWBaEK9LL+Ojut9q+X61q?= =?us-ascii?Q?EuzA3Z+iMJz2zK8WqJ6hl7G+E4TFaAuoGqHnElLzKrbh8cS+luFgLhHBTURn?= =?us-ascii?Q?vs6BPl/d35sNOmxWZMUgCT2ht4fdcQQVPuARFRPg0ZjyXwh0/XijM/sihUBn?= =?us-ascii?Q?qp1DZqUvP7lFF8GSncr5qf4JEWSFGLdIZHJ2vMNKINSD0nnFLCY6aJSTqSVw?= =?us-ascii?Q?EQ6G8mk44wB5DPIemvbNqAMMYxw0foZ8JXgVz9FmRO+7qrc4Td6Snzp4cybY?= =?us-ascii?Q?BG23lOk+Cyx5KPz++YGzypFkfjaIjiSdKE+pyFnRsn5ywRV/05i8V98uH/NK?= =?us-ascii?Q?IKyFXlTEHdE74nVVYq4erVR0gtlXp8ILJcirXRu62bEy2ZBv23qmI7xc7CAU?= =?us-ascii?Q?l9I26kkiVxx8PpSctVvoUgEtLsNDiNulGylkXZCZpNYvW5qhOD9WcbNzgr/g?= =?us-ascii?Q?eNGvM6XLI5xa2NUsBQwdyBI/6rsjnSOCmBj7PNZmmDI2gDX8SJ/bu1rmQ3Et?= =?us-ascii?Q?kGeMujSEJa2tpCgPpRAUuxgO+yn6L56CbiRkB9Zw5h2GIRT3AAw6wqs0w628?= =?us-ascii?Q?H5w0yv4E3okeAn33wef/Ir2HxhQDw6I4l65YGiH5?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB6953.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0236f9b8-e627-4c5d-1aae-08daa1680283 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2022 15:42:11.6695 (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: V2Obq5npKskaWXDPtfgWfUIBZp2X9upju4UNUIAa6oELgDjpFx4ss1fy16WNg7hKeeth+dOM2cseGDpCPJVDuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB7269 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 Andrew, Did you get a chance to review this patch? Please let me know your thoughts= on it. Regards, Yuan > -----Original Message----- > From: Wang, YuanX > Sent: Monday, September 26, 2022 5:41 PM > To: dev@dpdk.org; Thomas Monjalon ; Ferruh Yigit > ; Andrew Rybchenko > > Cc: mdr@ashroe.eu; Li, Xiaoyun ; Singh, Aman Deep > ; Zhang, Yuying ; > Zhang, Qi Z ; Yang, Qiming ; > jerinjacobk@gmail.com; viacheslavo@nvidia.com; > stephen@networkplumber.org; Ding, Xuan ; > hpothula@marvell.com; Tang, Yaqi ; Wang, YuanX > ; Wenxuan Wu > Subject: [PATCH v5 2/4] ethdev: introduce protocol hdr based buffer split >=20 > Currently, Rx buffer split supports length based split. With Rx queue off= load > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and Rx packet segment > configured, PMD will be able to split the received packets into multiple > segments. >=20 > However, length based buffer split is not suitable for NICs that do split= based > on protocol headers. Given an arbitrarily variable length in Rx packet > segment, it is almost impossible to pass a fixed protocol header to drive= r. > Besides, the existence of tunneling results in the composition of a packe= t is > various, which makes the situation even worse. >=20 > This patch extends current buffer split to support protocol header based > buffer split. A new proto_hdr field is introduced in the reserved field o= f > rte_eth_rxseg_split structure to specify protocol header. The proto_hdr f= ield > defines the split position of packet, splitting will always happen after = the > protocol header defined in the Rx packet segment. When Rx queue offload > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is enabled and corresponding > protocol header is configured, driver will split the ingress packets into > multiple segments. >=20 > Examples for proto_hdr field defines: > To split after ETH-IPV4-UDP, it should be defined as RTE_PTYPE_L2_ETHER | > RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP >=20 > For inner ETH-IPV4-UDP, it should be defined as > RTE_PTYPE_TUNNEL_GRENAT | RTE_PTYPE_INNER_L2_ETHER | > RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP >=20 > struct rte_eth_rxseg_split { > struct rte_mempool *mp; /* memory pools to allocate segment from = */ > uint16_t length; /* segment maximal data length, > configures split point */ > uint16_t offset; /* data offset from beginning > of mbuf data buffer */ > /** > * Proto_hdr defines a bit mask of the protocol sequence as > * RTE_PTYPE_*, configures split point. The last RTE_PTYPE* > * in the mask indicates the split position. > * For non-tunneling packets, the complete protocol sequence > * should be defined. > * For tunneling packets, for simplicity, only the tunnel and > * inner protocol sequence should be defined. > */ > uint32_t proto_hdr; > }; >=20 > If protocol header split can be supported by a PMD, the > rte_eth_buffer_split_get_supported_hdr_ptypes function can be use to > obtain a list of these protocol headers. >=20 > For example, let's suppose we configured the Rx queue with the following > segments: > seg0 - pool0, proto_hdr0=3DRTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4= , > off0=3D2B > seg1 - pool1, proto_hdr1=3DRTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 > | RTE_PTYPE_L4_UDP, off1=3D128B > seg2 - pool2, off1=3D0B >=20 > The packet consists of ETH_IPV4_UDP_PAYLOAD will be split like > following: > seg0 - ipv4 header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 > seg1 - udp header @ 128 in mbuf from pool1 > seg2 - payload @ 0 in mbuf from pool2 >=20 > Note: NIC will only do split when the packets exactly match all the proto= col > headers in the segments. For example, if ARP packets received with above > config, the NIC won't do split for ARP packets since it does not contains= ipv4 > header and udp header. These packets will be put into the last valid > mempool, with zero offset. >=20 > Now buffer split can be configured in two modes. For length based buffer > split, the mp, length, offset field in Rx packet segment should be config= ured, > while the proto_hdr field will be ignored. > For protocol header based buffer split, the mp, offset, proto_hdr field i= n Rx > packet segment should be configured, while the length field will be ignor= ed. >=20 > The split limitations imposed by underlying driver is reported in the > rte_eth_dev_info->rx_seg_capa field. The memory attributes for the split > parts may differ either, dpdk memory and external memory, respectively. >=20 > Signed-off-by: Yuan Wang > Signed-off-by: Xuan Ding > Signed-off-by: Wenxuan Wu > --- > doc/guides/rel_notes/release_22_11.rst | 7 +++ > lib/ethdev/rte_ethdev.c | 74 ++++++++++++++++++++++---- > lib/ethdev/rte_ethdev.h | 29 +++++++++- > 3 files changed, 98 insertions(+), 12 deletions(-) >=20 > diff --git a/doc/guides/rel_notes/release_22_11.rst > b/doc/guides/rel_notes/release_22_11.rst > index 8e5bdde46a..cce1f6e50c 100644 > --- a/doc/guides/rel_notes/release_22_11.rst > +++ b/doc/guides/rel_notes/release_22_11.rst > @@ -64,6 +64,13 @@ New Features > Added ``rte_eth_buffer_split_get_supported_hdr_ptypes()``, to get > supported > header protocols of a PMD to split. >=20 > +* **Added protocol header based buffer split.** > + > + Ethdev: The ``reserved`` field in the ``rte_eth_rxseg_split`` > + structure is replaced with ``proto_hdr`` to support protocol header ba= sed > buffer split. > + User can choose length or protocol header to configure buffer split > + according to NIC's capability. > + >=20 > Removed Items > ------------- > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index > 1f0a7f8f3f..27ec19faed 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -1649,9 +1649,10 @@ rte_eth_dev_is_removed(uint16_t port_id) } >=20 > static int > -rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg, > - uint16_t n_seg, uint32_t *mbp_buf_size, > - const struct rte_eth_dev_info *dev_info) > +rte_eth_rx_queue_check_split(uint16_t port_id, > + const struct rte_eth_rxseg_split *rx_seg, > + uint16_t n_seg, uint32_t *mbp_buf_size, > + const struct rte_eth_dev_info *dev_info) > { > const struct rte_eth_rxseg_capa *seg_capa =3D &dev_info- > >rx_seg_capa; > struct rte_mempool *mp_first; > @@ -1674,6 +1675,7 @@ rte_eth_rx_queue_check_split(const struct > rte_eth_rxseg_split *rx_seg, > struct rte_mempool *mpl =3D rx_seg[seg_idx].mp; > uint32_t length =3D rx_seg[seg_idx].length; > uint32_t offset =3D rx_seg[seg_idx].offset; > + uint32_t proto_hdr =3D rx_seg[seg_idx].proto_hdr; >=20 > if (mpl =3D=3D NULL) { > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n"); > @@ -1707,13 +1709,63 @@ rte_eth_rx_queue_check_split(const struct > rte_eth_rxseg_split *rx_seg, > } > offset +=3D seg_idx !=3D 0 ? 0 : RTE_PKTMBUF_HEADROOM; > *mbp_buf_size =3D rte_pktmbuf_data_room_size(mpl); > - length =3D length !=3D 0 ? length : *mbp_buf_size; > - if (*mbp_buf_size < length + offset) { > - RTE_ETHDEV_LOG(ERR, > - "%s mbuf_data_room_size %u < %u > (segment length=3D%u + segment offset=3D%u)\n", > - mpl->name, *mbp_buf_size, > - length + offset, length, offset); > - return -EINVAL; > + > + if (proto_hdr > 0) { > + /* Split based on protocol headers. */ > + > + /* skip the payload */ > + if (proto_hdr =3D=3D RTE_PTYPE_ALL_MASK) > + continue; > + > + int ptype_cnt; > + > + ptype_cnt =3D > rte_eth_buffer_split_get_supported_hdr_ptypes(port_id, NULL, 0); > + if (ptype_cnt <=3D 0) { > + RTE_ETHDEV_LOG(ERR, > + "Port %u failed to supported buffer > split header protocols\n", > + port_id); > + return -EINVAL; > + } > + > + uint32_t ptypes[ptype_cnt]; > + int i; > + > + ptype_cnt =3D > rte_eth_buffer_split_get_supported_hdr_ptypes(port_id, > + > ptypes, ptype_cnt); > + if (ptype_cnt < 0) { > + RTE_ETHDEV_LOG(ERR, > + "Port %u failed to supported buffer > split header protocols\n", > + port_id); > + return -EINVAL; > + } > + > + for (i =3D 0; i < ptype_cnt; i++) > + if (ptypes[i] =3D=3D proto_hdr) > + break; > + if (i =3D=3D ptype_cnt) { > + RTE_ETHDEV_LOG(ERR, > + "Requested Rx split header protocols > 0x%x is not supported.\n", > + proto_hdr); > + return -EINVAL; > + } > + > + if (*mbp_buf_size < offset) { > + RTE_ETHDEV_LOG(ERR, > + "%s > mbuf_data_room_size %u < %u segment offset)\n", > + mpl->name, *mbp_buf_size, > + offset); > + return -EINVAL; > + } > + } else { > + /* Split at fixed length. */ > + length =3D length !=3D 0 ? length : *mbp_buf_size; > + if (*mbp_buf_size < length + offset) { > + RTE_ETHDEV_LOG(ERR, > + "%s mbuf_data_room_size %u < %u > (segment length=3D%u + segment offset=3D%u)\n", > + mpl->name, *mbp_buf_size, > + length + offset, length, offset); > + return -EINVAL; > + } > } > } > return 0; > @@ -1793,7 +1845,7 @@ rte_eth_rx_queue_setup(uint16_t port_id, > uint16_t rx_queue_id, > n_seg =3D rx_conf->rx_nseg; >=20 > if (rx_conf->offloads & > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT) { > - ret =3D rte_eth_rx_queue_check_split(rx_seg, n_seg, > + ret =3D rte_eth_rx_queue_check_split(port_id, rx_seg, > n_seg, > &mbp_buf_size, > &dev_info); > if (ret !=3D 0) > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index > c440e3863a..ba7c11f735 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -994,6 +994,9 @@ struct rte_eth_txmode { > * specified in the first array element, the second buffer, from the > * pool in the second element, and so on. > * > + * - The proto_hdrs in the elements define the split position of > + * received packets. > + * > * - The offsets from the segment description elements specify > * the data offset from the buffer beginning except the first mbuf. > * The first segment offset is added with RTE_PKTMBUF_HEADROOM. > @@ -1015,12 +1018,36 @@ struct rte_eth_txmode { > * - pool from the last valid element > * - the buffer size from this pool > * - zero offset > + * > + * - Length based buffer split: > + * - mp, length, offset should be configured. > + * - The proto_hdr field will be ignored. > + * > + * - Protocol header based buffer split: > + * - mp, offset, proto_hdr should be configured. > + * - The length field will be ignored. > + * > + * - For Protocol header based buffer split, if the received packets > + * don't exactly match all protocol headers in the elements, packets > + * will not be split. > + * These packets will be put into: > + * - pool from the last valid element > + * - the buffer size from this pool > + * - zero offset > */ > 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. */ > + /** > + * Proto_hdr defines a bit mask of the protocol sequence as > RTE_PTYPE_*, > + * configures split point. The last RTE_PTYPE* in the mask indicates > the > + * split position. > + * For non-tunneling packets, the complete protocol sequence > should be defined. > + * For tunneling packets, for simplicity, only the tunnel and inner > + * protocol sequence should be defined. > + */ > + uint32_t proto_hdr; > }; >=20 > /** > -- > 2.25.1