From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8D11C433F5 for ; Sun, 2 Oct 2022 04:02:02 +0000 (UTC) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 939C340146; Sun, 2 Oct 2022 06:02:01 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 7FA9E400D5 for ; Sun, 2 Oct 2022 06:01:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664683319; x=1696219319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jIjNZpgYGQWf8tHjQH+KCiqWvrtDTuLtuaj875SIL6s=; b=PNyMfnV5i1X95O+q6cJG3cxfF4y4DXbPT5XUdfYtW/1sAoFpmi5dfmbc amARAxA7eVyT0cB/jh7CQgXeaLrcxkXthsJJQTpF40jdKCWNiMgUhDFTr gC7oLUnQrzEqu0sIpLETTaj9xI9lMhIJjJ5N5LOg1VD0I1ePbBUSTDbIL Ly8KXE4Ka6B4NLRNEN05U50+qlukpOqZ+DftdEEv2Xe+nJ+nzQsh3ys2R lBLipMjhaaNkLbdfgqaT3y9SnNR7yXoaM6AW/pyVEEg65f9A/l7U5MyPk /dCQElgpmzcXVhGQHcmuroiiAQmJ8tIY67YriWN35gG2P93tQGiF5plsk Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10487"; a="285576793" X-IronPort-AV: E=Sophos;i="5.93,361,1654585200"; d="scan'208";a="285576793" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2022 21:01:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10487"; a="623188719" X-IronPort-AV: E=Sophos;i="5.93,361,1654585200"; d="scan'208";a="623188719" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga002.jf.intel.com with ESMTP; 01 Oct 2022 21:01:57 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 1 Oct 2022 21:01:57 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Sat, 1 Oct 2022 21:01:57 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.48) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Sat, 1 Oct 2022 21:01:57 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KUCVo9O0QIzXVenGpxo0A1cWVMVlZGS2gROL9nFDG+prBxtdr011xs05quckXYR3kHkjhE7WRSYlD8fvvOuz91KY6Tf6OcYmhdCRoQ00SA5q5Az6HgXjCHKnRQ+jBsd9khwwHUqQzJQXYdHQMuaQtOw7LIVL9FGE6JeYMBl1j314WS/t56+zrKc3iyfPc6UNUPp0nVDm5aP428/tHzYw5MvY26S6tez4J29juxzz2gVk4PL/72GHXHmgREKqL7ySrRkui+PzqVqy2Sy3hf6PQz/cjcNJBwzlfi6IeWYmsb4QrxvRTImvWA1VEzxt1Z7Wn1Z0yBJ2LogVtNdZLIXsDg== 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=y/SVVPmz1wNaREwfO/tMX+2S0/uDl4s3pjHXUUFXB00=; b=HDf9KGmUBsOtexFcNCK8hy/8YNbkwieOq0idlyyjzFF7fqLFJ+/mN4Lk0+4KHdRGfeAHBMGwXXi7N7iTQ1FWL6MA6qlUQ99I4kIjFJ5yheqb69AIdMNo6nSFfy33cpUASdgehu3KL4J1QOT1y74XF6Gd7wBytPHXvZzVmn5aZUnqYgvBEELQWaSz4K4PMHB0C0beyz2ul+v0HKWuC7I2NdQ4CAw1O2R8QBYf/cUzmKWZvKnqa/aLxzxeESoug65CCb89o1IrduWkVteblty2j/CN3R7rOQk4IbIqbRfmQYbWXEBFZ01lgG1dfjj9mlmtueZRNElWmvMo+kQWxjpXQQ== 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 SJ0PR11MB4959.namprd11.prod.outlook.com (2603:10b6:a03:2de::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23; Sun, 2 Oct 2022 04:01:55 +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; Sun, 2 Oct 2022 04:01:54 +0000 From: "Wang, YuanX" To: Andrew Rybchenko , Thomas Monjalon , Ferruh Yigit CC: "ferruh.yigit@xilinx.com" , "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" , Wenxuan Wu , "dev@dpdk.org" Subject: RE: [PATCH v7 2/4] ethdev: introduce protocol hdr based buffer split Thread-Topic: [PATCH v7 2/4] ethdev: introduce protocol hdr based buffer split Thread-Index: AQHY1ZhlXaioO8sLvUaSg1zago8hm636enGA Date: Sun, 2 Oct 2022 04:01:54 +0000 Message-ID: References: <20220812181552.2908067-1-yuanx.wang@intel.com> <20221001210521.15955-1-yuanx.wang@intel.com> <20221001210521.15955-3-yuanx.wang@intel.com> In-Reply-To: <20221001210521.15955-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_|SJ0PR11MB4959:EE_ x-ms-office365-filtering-correlation-id: 35fb50aa-835b-4249-27c6-08daa42ad7f3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dvnlZPWAmCJf5z5GqNjB86F14nDzJ6HwzOhBo4wsTiXMZ4LTAxsoUvZZOJnn1VbSVRGP6JnK//5y7cYNthSvbwjunEaTbujCzNTaMnt8GR4k4MFavFU+/x5AcWJzV5kZG9+8QiqQUeebquAGaXZvLExcK17LAC9sZttqxuZpqPutMVdRDRlvyiBNzGeYzZ9PjEI3thZYhiPHJvCUb33bbD2R7LWUaJ8c4LhbtMA3y+WPLYkU1rMvop/5oYRu5/3Nn6YnMXNI55+panbzdY5/RAMrzy4Ueba2Mf1oDuk8w89gvnhtkus1K014u+tt0oSpnr3wzXNKJNjEBiiih2VHCGlC+6WVKgo3sqM+rBXQrmA+DowOZ5H73zWE30sc3fEVjpZm9y3wReMBF8jmtgGgj4w0frTvxGMjYEYy0OWZA2LgERcY1O6oNmVxvPaxECqy1O3xLdAbYUT/l9W8HLG6RQ08hbB0fI8TKuPO53vKIrM7z4Na612XCJgT6gfKalRH2498HpcKqHaf17mpBAUVC0i/zq2n73f+fSKWZ8R6x9iVm4qk6DQgUC/RUQaHkak+2Ha9uwg7Yrdja3o+915P4d81Q8XrheLWWfvWqVaMEH4T1+oiVMgxextjEZ5Virbr7o8MElrHsio6u3+XbYK83r5iEmPCmgRRuOFLTSi9cJiYwAqbN42d3Zf/8Mfo+A4N4EL4dAPp4HSZ+nBMsmveIp4VQyc9zznp6Rfsng5sxrNb9skVAnGnS4dq7jdipyLQw20bmaQLFYX+cjzh1fslEg== 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)(396003)(136003)(39860400002)(376002)(366004)(451199015)(2906002)(83380400001)(38070700005)(82960400001)(33656002)(86362001)(38100700002)(122000001)(186003)(55016003)(64756008)(66556008)(66476007)(66446008)(76116006)(66946007)(316002)(54906003)(110136005)(71200400001)(41300700001)(7696005)(53546011)(30864003)(478600001)(26005)(9686003)(6506007)(7416002)(5660300002)(52536014)(8936002)(8676002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?c8b2+/tVDOQYwlxH4FCjvCQ20u9HozFgxLf28cYEJDrmerv+146Uguo93JQ+?= =?us-ascii?Q?yGe0QCOKZSVlcw372ngDlJPjZUMQZ+w9f87s86VVkr1QoDLCfUzuY6wRR3WQ?= =?us-ascii?Q?/r/AA5T2tqA0xcyLdLrnszLhCEZ4GcR11g73wrj2Ov9Ok0OInD8ANPA+iHs2?= =?us-ascii?Q?15rhZU3ur4XYmN3NzpTmAwN7C+0yQHmvBUzdW+s224xUxytM+qMt5QCOLo7f?= =?us-ascii?Q?FDRJlndFMmfBB0V6UY7BaJRYv2ASC/h+xF9PRl1koLu0c87xdR/wZl15R+ih?= =?us-ascii?Q?PDRG2+/ngAhVVTn1dUIxlJcuPkY968ajZzO2cG8PuUO4N9yR2ViGYJS0g4Ky?= =?us-ascii?Q?hZZMdwD1MgUidD4/GvkOYPaOZFknLVI9mZWxazNy9kDC3NMpLfnU137u788A?= =?us-ascii?Q?J1Ph3Qm8l4wJcLmEeJbZU31TjcInuWOBQKhDvQGmrH9GL1qFcfrNQSkxOQHz?= =?us-ascii?Q?U+Kt1Z6vZk2KtnwMLCg9j56k0M7mCMoj341EfG+nQWW1fLGh3GvQkOm1TD5d?= =?us-ascii?Q?a7Q0H2sMsAUVbxxBf1Oh0jtFjW1hOTYBZRa5vQwjGC3eBRZvNEtVNCW3Rvhe?= =?us-ascii?Q?iOpKr9XBB0OJ/Xv+sXSYURsEm72WePMv++drGiryRvPlAlu774zABpjscNjI?= =?us-ascii?Q?mKEZSUbqXEXEfRSOh3j7HYbYWFEL46DzvGyNLQIa27VXPscKAv9kOQYYRj3D?= =?us-ascii?Q?hiy2RKNI+1ZbCAgEt/iySRQl7H6XTI6bK6y4kfq6Ds7fkgS5KMVlcIjZnD0h?= =?us-ascii?Q?kDF7I1O9PXfn9CBzWAAcYfhHCqgN6WykZ5RVSeaJPjTfay2nPOvn2CZpUsGu?= =?us-ascii?Q?fYT6uqQt0VX93mGadEUBiYJhjv5aIXsr0uWE3J7KM9IJAyW4/jm7TEa7AAxp?= =?us-ascii?Q?pPtd9avW9BJRedsxTKkC2uG78V8F6G5JfCHEthNXGjuzeBDKvSjldquDpDxH?= =?us-ascii?Q?pP5lWPYN28Aslafkk7t+ThwR+UqXcMVz+dFoMZl46QY9xtXFukyYxQVYcb42?= =?us-ascii?Q?iVwHnRbQbmxcLAqe+Tpw3U95aDUh96SSYlULU8jFPK+GNmFL/o0h4D+r0DNo?= =?us-ascii?Q?EZ42dqVHZNlnQrT7HsALCjj+j3VqIuGuDyKm2RpN4YN++e6tMaUEeVv5+9md?= =?us-ascii?Q?/f77fwdMugZfgFd91Le1RfLiVLohMQlnUUuJIyYQxGofEjeyxSTsJEQZyzb2?= =?us-ascii?Q?A2zNXBVw0uqHBm6Cz/nBYT6GOEfCfNKAsKHH0j7ZluvCj0iw/Kk24t4Tc//Z?= =?us-ascii?Q?cTE/Pou3LSjTLBannPvaRB4pBYzWl4z/rpKMHxpbxkZrqD7Vg+bH7u9gYnzm?= =?us-ascii?Q?8IAywSVEffWcrA8iwLGboYO4nszaiS8AHTd7aV46yoqM5YIV5G19bH+M3gdv?= =?us-ascii?Q?MFTGYdlr6vprbtdY7IkKFnbquiOi+eqodWbJJoSM/tgSyEQu+XEKmeZ4Nk67?= =?us-ascii?Q?zKaxwlVlwFRy8jB05OPflcstyTMofezIcPROZAPrh8mhf9HWH7MfG9w2Zmnj?= =?us-ascii?Q?wu9Dh6jXGk3Fk/WEABK9hfjXjQ5AMCYQ3v9cHgWHTt+bUseiFk0Jr+3PklDO?= =?us-ascii?Q?jFFsX9uzylcoOlmFzatqkt1enDi403tgr3qpPJ3f?= 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: 35fb50aa-835b-4249-27c6-08daa42ad7f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2022 04:01:54.4496 (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: 6I0mH/0OMKLCj5LMxHkna3mjylHDe6dMXYDBLNfZcgI0q6DwSW8SvKMODqM0ZcktDQY/CjFl7cJxJseAWCA8qQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4959 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 All, Could you please review and provide suggestions if any. Thanks, Yuan > -----Original Message----- > From: Wang, YuanX > Sent: Sunday, October 2, 2022 5:05 AM > To: dev@dpdk.org; Thomas Monjalon ; Ferruh Yigit > ; Andrew Rybchenko > > Cc: ferruh.yigit@xilinx.com; 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 v7 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 6a7474a3d6..510869c73a 100644 > --- a/doc/guides/rel_notes/release_22_11.rst > +++ b/doc/guides/rel_notes/release_22_11.rst > @@ -101,6 +101,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`` struct= ure is > + replaced with ``proto_hdr`` to support protocol header based 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 > cf14e04010..a5f9647bd3 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