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 56A7AA0506; Tue, 29 Mar 2022 09:56:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EAE7142807; Tue, 29 Mar 2022 09:56:24 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 9988640691 for ; Tue, 29 Mar 2022 09:56: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=1648540583; x=1680076583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jROxEHF1MEjsqAkIu6Zy5qGNktIIRWvksJDioO1Bbcg=; b=QaG2S1PL+0BMDBc9D1BY3JGJaAwFFJ7JR/bUITQdTdZ6oOvlnn2wl/fJ eVEk9xzo+XFFBNhM2sKh4QBuyZKK6pK3DIpscQZ7x2nQt3SUa0tRWP83m GkDLM3w92lLDfpjvHIh52pfh+aPWc/Kv6WJz4bWgq1TqEv7SlZMRFxK/G eDAtZTIniPcZiunYdC47bewdWwaA6MeQhX3xU+UoGiupDVWLXiVPIK8V6 cl6GLAUWvl435BSJg5nQntUq8mGOYjudTfZdfnPsvGIDbz2+AmKF8bh4o 6QzHevDH6GheYgiyLgnimuoSE99fzcxFmKZZwu7qMNj7Uhkbo9P/63HLS A==; X-IronPort-AV: E=McAfee;i="6200,9189,10300"; a="259375533" X-IronPort-AV: E=Sophos;i="5.90,219,1643702400"; d="scan'208";a="259375533" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2022 00:56:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,219,1643702400"; d="scan'208";a="639242935" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by FMSMGA003.fm.intel.com with ESMTP; 29 Mar 2022 00:56:22 -0700 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 29 Mar 2022 00:56:21 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX603.ccr.corp.intel.com (10.109.6.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 29 Mar 2022 15:56:19 +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.027; Tue, 29 Mar 2022 15:56:19 +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,v3 1/3] ethdev: introduce protocol type based header split Thread-Topic: [RFC,v3 1/3] ethdev: introduce protocol type based header split Thread-Index: AQHYQznLIUjgSYZqRUeBqTow5snoyKzV89/g Date: Tue, 29 Mar 2022 07:56:19 +0000 Message-ID: References: <20220303060136.36427-1-xuan.ding@intel.com> <20220329064945.54777-1-xuan.ding@intel.com> <20220329064945.54777-2-xuan.ding@intel.com> In-Reply-To: <20220329064945.54777-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 29, 2022 2:50 PM > 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,v3 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, configuring buffer spl= it based > on length is not suitable for NICs that do split based on header protocol= types. > Because tunneling makes the conversion from length to protocol type > impossible. >=20 > This patch extends the current buffer split to support protocol type and > offset based header split. A new proto field is introduced in the > rte_eth_rxseg_split structure reserved field to specify header protocol t= ype. > With Rx offload flag RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and > protocol type configured, PMD will split the ingress packets into two sep= arate > regions. Currently, both inner and outer L2/L3/L4 level header split can = be > supported. >=20 > For example, let's suppose we configured the Rx queue with the following > segments: > seg0 - pool0, off0=3D2B > seg1 - pool1, off1=3D128B >=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 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 > seg1 - payload @ 128 in mbuf from pool1 >=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 | 34 ++++++++++++++++++++++------- > lib/ethdev/rte_ethdev.h | 48 > +++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 72 insertions(+), 10 deletions(-) >=20 > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index > 29a3d80466..144a43588c 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"); > @@ -1694,13 +1695,29 @@ 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 =3D=3D 0) { use RTE_ETH_RX_HEADER_SPLIT_NONE looks better? Reviewed-by: Qi Zhang