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 41D55A04FF; Tue, 22 Mar 2022 08:14:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2962B427ED; Tue, 22 Mar 2022 08:14:24 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id A0408410E5 for ; Tue, 22 Mar 2022 08:14:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647933262; x=1679469262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5Nb99GZomnfUpC9PRXGFCUAsLg0CQifOkQVc2VIdyg0=; b=hYVECD3a+uW7wFs3X1BrS2E3lloADfRqWbgCuQvDqoDhZrnSSZWMA82v 2osMq/CP4JJ2alhK2Y4AprT38KNH0T8VKgP/f4MeqGwzU7Mh1F5Q2zqSv zv88Lc6xuUzKXsB8lDBybOD+WszMVhtB/wszcuukfmnc1BgR8H/poGvVM XW2wI0t3Rx77MEnemPQEKkLtkRgcms8oJomf58ylOzKFCVAlzqh52EbHf yEjrwwV5KDksQHUTwE787np+6ilPWLJuJPb41AV60YXC3/q1IJidz2pgS RPJx1LuYiiQ1adTPjfogrSHlPrw43RH9lWWPXtdISHCnyWMchEH9uAWLD Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10293"; a="257935928" X-IronPort-AV: E=Sophos;i="5.90,201,1643702400"; d="scan'208";a="257935928" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2022 00:14:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,201,1643702400"; d="scan'208";a="518766380" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga006.jf.intel.com with ESMTP; 22 Mar 2022 00:14:21 -0700 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 22 Mar 2022 00:14:20 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX606.ccr.corp.intel.com (10.109.6.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 22 Mar 2022 15:14:18 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2308.021; Tue, 22 Mar 2022 15:14:18 +0800 From: "Zhang, Qi Z" To: "Ding, Xuan" , "thomas@monjalon.net" , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" CC: "dev@dpdk.org" , "stephen@networkplumber.org" , "mb@smartsharesystems.com" , "viacheslavo@nvidia.com" , "Yu, Ping" , "Wu, WenxuanX" , "Wang, YuanX" Subject: RE: [RFC,v2 1/3] ethdev: introduce protocol type based header split Thread-Topic: [RFC,v2 1/3] ethdev: introduce protocol type based header split Thread-Index: AQHYPaFRcZKvXqFl60G/OFVB4QIcNazK+jEA Date: Tue, 22 Mar 2022 07:14:18 +0000 Message-ID: <7912b7c67946402186fd8e318715d5a0@intel.com> References: <20220303060136.36427-1-xuan.ding@intel.com> <20220322035629.18756-1-xuan.ding@intel.com> <20220322035629.18756-2-xuan.ding@intel.com> In-Reply-To: <20220322035629.18756-2-xuan.ding@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > -----Original Message----- > From: Ding, Xuan > Sent: Tuesday, March 22, 2022 11:56 AM > To: thomas@monjalon.net; Yigit, Ferruh ; > andrew.rybchenko@oktetlabs.ru > Cc: dev@dpdk.org; stephen@networkplumber.org; > mb@smartsharesystems.com; viacheslavo@nvidia.com; Zhang, Qi Z > ; Yu, Ping ; Wu, WenxuanX > ; Ding, Xuan ; Wang, > YuanX > Subject: [RFC,v2 1/3] ethdev: introduce protocol type based header split >=20 > From: Xuan Ding >=20 > Header split consists of splitting a received packet into two separate re= gions > based on the packet content. The split happens after the packet header an= d > before the packet payload. 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. >=20 > Currently, Rx buffer split supports length and offset based packet split. > Although header split is a subset of buffer split, configure buffer split= based > on length and offset is not suitable for NICs that do split based on head= er > protocol types. And tunneling makes the conversion from offset to protoco= l > impossible. >=20 > This patch extends the current buffer split to support protocol based hea= der > split. A new proto field is introduced in the rte_eth_rxseg_split structu= re > reserved field to specify header protocol type. 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, both inner and outer L2/L3/L4 level header split can be suppor= ted. >=20 > For example, let's suppose we configured the Rx queue with the following > segments: > seg0 - pool0 > seg1 - pool1 >=20 > With header split type configured with RTE_ETH_RX_HEADER_SPLIT_UDP, > the packet consists of MAC_IP_UDP_PAYLOAD will be split like following: > seg0 - pool0, udp_header > seg1 - pool1, payload >=20 > The memory attributes for the split parts may differ either - for example= the > mempool0 and mempool1 belong to dpdk memory and external memory, > respectively. >=20 > Signed-off-by: Xuan Ding > Signed-off-by: Yuan Wang > --- > lib/ethdev/rte_ethdev.c | 24 +++++++++++++---------- > lib/ethdev/rte_ethdev.h | 43 > +++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 55 insertions(+), 12 deletions(-) >=20 > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index > 70c850a2f1..49c8fef1c3 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -1661,6 +1661,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; > + uint16_t proto =3D rx_seg[seg_idx].proto; >=20 > if (mpl =3D=3D NULL) { > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n"); > @@ -1692,15 +1693,17 @@ rte_eth_rx_queue_check_split(const struct > rte_eth_rxseg_split *rx_seg, > (struct rte_pktmbuf_pool_private)); > return -ENOSPC; > } > - 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 =3D=3D 0) { > + 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; > + } > } As the length and proto is exclusive, it better also check the length when = proto!=3D0 ..... > @@ -1197,12 +1197,26 @@ struct rte_eth_txmode { > * - pool from the last valid element > * - the buffer size from this pool > * - zero offset > + * > + * Header split is a subset of buffer split. The split happens after > + the > + * packet header and before the packet payload. For PMDs that do not > + * support header split configuration by length and offset, the > + location > + * of the split needs to be specified by the header protocol type. > + While for > + * buffer split, this field should not be configured. > + * > + * If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT flag is set in offloads field, > + * the PMD will split the received packets into two separate regions: > + * - The header buffer will be allocated from the memory pool, > + * specified in the first array element, the second buffer, from the > + * pool in the second element. > + * - The length and offset do not need to be configured in header split. We may not necessarily ignore the offset configure for header split as ther= e is no confliction, a driver still can support copying a split header to a= specific mbuf offset And if we support offset with header split, offset boundary check can also = be considered in rte_eth_rx_queue_check_split Regards Qi