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 0BB87A00C4; Tue, 26 Apr 2022 13:36:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 915F441143; Tue, 26 Apr 2022 13:36:28 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id B355A41141 for ; Tue, 26 Apr 2022 13:36:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650972986; x=1682508986; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WBiCLTgdwpNjQy2SRlebhE39QpMAdC8BAswAv2NIQFI=; b=Pc9DYNoE9PGURAvdqFAuKKO9O7ZgdKdG8PlVoaO9P1lZLyD8LY47rbUM kGCA02iVMGcCT9y+2txtzSrW1NCJVQkzk6vMTYzZH+SHynIACP7we2HAq TJdcwFJw/u7OXwxyJO+mzff79vHg9w1zGu2CaP/ZU6RYtAZAvJ6tBAj9a vy2uJZ72ilIrkQtWHdiyRTXgXgItrUXNFXAraMBdKTjMpRkCfjQ4yv+1Z mPHETmdjG9VgQy8To5Gz7I+7buFl5vVaaSK5vTrkytNveEECSD3r0mVl/ XMJqqkBlnGmVgYbxE/wghshfdpA/gjj6PFKrHA9A1WEXDMtBOB/U5E6bL Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="265714207" X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="265714207" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 04:36:26 -0700 X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="579842308" Received: from unknown (HELO localhost.localdomain) ([10.239.251.3]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 04:36:21 -0700 From: wenxuanx.wu@intel.com To: thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, xiaoyun.li@intel.com, ferruh.yigit@xilinx.com, aman.deep.singh@intel.com, dev@dpdk.org, yuying.zhang@intel.com, qi.z.zhang@intel.com, jerinjacobk@gmail.com Cc: stephen@networkplumber.org, mb@smartsharesystems.com, viacheslavo@nvidia.com, ping.yu@intel.com, xuan.ding@intel.com, yuanx.wang@intel.com, wenxuanx.wu@intel.com Subject: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split Date: Tue, 26 Apr 2022 11:13:36 +0000 Message-Id: <20220426111338.1074785-2-wenxuanx.wu@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220426111338.1074785-1-wenxuanx.wu@intel.com> References: <20220402104109.472078-2-wenxuanx.wu@intel.com> <20220426111338.1074785-1-wenxuanx.wu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 From: Wenxuan Wu Protocol based buffer split consists of splitting a received packet into two separate regions based on its content. The split happens after the packet protocol header and before the packet payload. Splitting is usually between the packet protocol header that can be posted to a dedicated buffer and the packet payload that can be posted to a different buffer. Currently, Rx buffer split supports length and offset based packet split. protocol split is based on buffer split, configuring length of buffer split is not suitable for NICs that do split based on protocol types. Because tunneling makes the conversion from length to protocol type impossible. This patch extends the current buffer split to support protocol and offset based buffer split. A new proto field is introduced in the rte_eth_rxseg_split structure reserved field to specify header protocol type. With Rx queue offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and corresponding protocol type configured. PMD will split the ingress packets into two separate regions. Currently, both inner and outer L2/L3/L4 level protocol based buffer split can be supported. For example, let's suppose we configured the Rx queue with the following segments: seg0 - pool0, off0=2B seg1 - pool1, off1=128B With protocol split type configured with RTE_PTYPE_L4_UDP. The packet consists of MAC_IP_UDP_PAYLOAD will be splitted like following: seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 seg1 - payload @ 128 in mbuf from pool1 The memory attributes for the split parts may differ either - for example the mempool0 and mempool1 belong to dpdk memory and external memory, respectively. Signed-off-by: Xuan Ding Signed-off-by: Yuan Wang Signed-off-by: Wenxuan Wu Reviewed-by: Qi Zhang --- lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++------- lib/ethdev/rte_ethdev.h | 15 ++++++++++++++- 2 files changed, 43 insertions(+), 8 deletions(-) diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index 29a3d80466..1a2bc172ab 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 = rx_seg[seg_idx].mp; uint32_t length = rx_seg[seg_idx].length; uint32_t offset = rx_seg[seg_idx].offset; + uint32_t proto = rx_seg[seg_idx].proto; if (mpl == NULL) { RTE_ETHDEV_LOG(ERR, "null mempool pointer\n"); @@ -1694,13 +1695,34 @@ rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg, } offset += seg_idx != 0 ? 0 : RTE_PKTMBUF_HEADROOM; *mbp_buf_size = rte_pktmbuf_data_room_size(mpl); - length = length != 0 ? length : *mbp_buf_size; - if (*mbp_buf_size < length + offset) { - RTE_ETHDEV_LOG(ERR, - "%s mbuf_data_room_size %u < %u (segment length=%u + segment offset=%u)\n", - mpl->name, *mbp_buf_size, - length + offset, length, offset); - return -EINVAL; + if (proto == 0) { + length = length != 0 ? length : *mbp_buf_size; + if (*mbp_buf_size < length + offset) { + RTE_ETHDEV_LOG(ERR, + "%s mbuf_data_room_size %u < %u (segment length=%u + segment offset=%u)\n", + mpl->name, *mbp_buf_size, + length + offset, length, offset); + return -EINVAL; + } + } else { + /* Ensure n_seg is 2 in protocol based buffer split. */ + if (n_seg != 2) { + RTE_ETHDEV_LOG(ERR, "number of buffer split protocol segments should be 2.\n"); + return -EINVAL; + } + /* Length and protocol are exclusive here, so make sure length is 0 in protocol + based buffer split. */ + if (length != 0) { + RTE_ETHDEV_LOG(ERR, "segment length should be set to zero in buffer split\n"); + 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; + } } } return 0; diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index 04cff8ee10..ef7f59aae6 100644 --- a/lib/ethdev/rte_ethdev.h +++ b/lib/ethdev/rte_ethdev.h @@ -1187,6 +1187,9 @@ struct rte_eth_txmode { * mbuf) the following data will be pushed to the next segment * up to its own length, and so on. * + * + * - The proto in the elements defines the split position of received packets. + * * - If the length in the segment description element is zero * the actual buffer size will be deduced from the appropriate * memory pool properties. @@ -1197,12 +1200,21 @@ 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 should not be configured in length split. Zero default. + * + * - Protocol based buffer split: + * - mp, offset, proto should be configured. + * - The length should not be configured in protocol split. Zero default. + * */ 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. */ + uint32_t proto; /**< Protocol of buffer split, determines protocol split point. */ }; /** @@ -1664,6 +1676,7 @@ struct rte_eth_conf { RTE_ETH_RX_OFFLOAD_QINQ_STRIP) #define DEV_RX_OFFLOAD_VLAN RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN) RTE_ETH_RX_OFFLOAD_VLAN + /* * If new Rx offload capabilities are defined, they also must be * mentioned in rte_rx_offload_names in rte_ethdev.c file. -- 2.25.1