From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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" <qi.z.zhang@intel.com>
To: "Ding, Xuan" <xuan.ding@intel.com>, "thomas@monjalon.net"
<thomas@monjalon.net>, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>
CC: "dev@dpdk.org" <dev@dpdk.org>, "stephen@networkplumber.org"
<stephen@networkplumber.org>, "mb@smartsharesystems.com"
<mb@smartsharesystems.com>, "viacheslavo@nvidia.com"
<viacheslavo@nvidia.com>, "Yu, Ping" <ping.yu@intel.com>, "Wu, WenxuanX"
<wenxuanx.wu@intel.com>, "Wang, YuanX" <yuanx.wang@intel.com>
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: <e60a5d7d683047a89ceacf5f7936d57c@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
> -----Original Message-----
> From: Ding, Xuan <xuan.ding@intel.com>
> Sent: Tuesday, March 29, 2022 2:50 PM
> To: thomas@monjalon.net; Yigit, Ferruh <ferruh.yigit@intel.com>;
> andrew.rybchenko@oktetlabs.ru
> Cc: dev@dpdk.org; stephen@networkplumber.org;
> mb@smartsharesystems.com; viacheslavo@nvidia.com; Zhang, Qi Z
> <qi.z.zhang@intel.com>; Yu, Ping <ping.yu@intel.com>; Wu, WenxuanX
> <wenxuanx.wu@intel.com>; Ding, Xuan <xuan.ding@intel.com>; Wang,
> YuanX <yuanx.wang@intel.com>
> Subject: [RFC,v3 1/3] ethdev: introduce protocol type based header split
>=20
> From: Xuan Ding <xuan.ding@intel.com>
>=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 <xuan.ding@intel.com>
> Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> ---
> 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 <qi.z.zhang@intel.com>