From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 94472A04A9; Thu, 6 Aug 2020 23:43:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 678D12BF2; Thu, 6 Aug 2020 23:43:03 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 2488B2BF1 for ; Thu, 6 Aug 2020 23:43:02 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 82D2458016F; Thu, 6 Aug 2020 17:43:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 06 Aug 2020 17:43:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= iuKLsQYVCZ/NSPMgQzBLuQxzaJqB9tdq4soU8IoEkno=; b=eu+Wmh1sBPzzPDH4 jR9H1KQgq7giqeGL1RUPlJpv0xrvUEDBEPNXyfsrowHfWoYYbn3jxDZup5FBKKfL xsEiw2XHpZa5T1U7GOkgjh15drIHW4yqm2CGfAeYH3bvWA3SPXZgv6prBTH9aHSz P/SKikfd1kSc3tBPViQ5j79KlPLVVCcwIbFipV8sqyLDGprgNLSW/50HngVOqfRn 6arbm7o9lK0pUGSbGQffgO08JDP5iXRP1zP+P/eYjE/GQ7FknQXiHWtbEd9VZJek Vn3X6VDHvK4RR+DXFsQSw4yENhLHnnStpls2sggHkb/ekw8sEJ6Rp2+Q1isOrf3I Pqb0Mw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=iuKLsQYVCZ/NSPMgQzBLuQxzaJqB9tdq4soU8IoEk no=; b=uRNCHBLUurhJ/sj+SWAPTLZpqsa8Qu1F36Ap7/ICa4iRn7s8cs/TzufgU BI307iVYldxmAAHlIBSHmFHAK1o10ABS77tPlmmCpLwEeu60iO+FdtLZ/yAc3bWW YDNPsB4YLwz6jN3ToulKEFFoOtA70cXMKhuS1SdPko0XKSLsi6RYke2P4yRCkgjQ IY2P2el8rVImYIzdVFyXooWnYS7igdS9TvyLHPIDJmDvhDuVjzohLvzkEsNyKC6T sKZgKBDJ0L95s3iUhiod/hiYyzQkr7gzh+ZyxMnNIkHBT8SbM0/ToDDj8HDwkKHy iq9gd7aZH9i02Xp3S8iAZJoaxZT6g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkedugddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 96D5330600A9; Thu, 6 Aug 2020 17:42:57 -0400 (EDT) From: Thomas Monjalon To: Viacheslav Ovsiienko Cc: dev@dpdk.org, matan@mellanox.com, rasland@mellanox.com, ferruh.yigit@intel.com, jerinjacobk@gmail.com, stephen@networkplumber.org, ajit.khaparde@broadcom.com, maxime.coquelin@redhat.com, olivier.matz@6wind.com, david.marchand@redhat.com, Andrew Rybchenko Date: Thu, 06 Aug 2020 23:42:55 +0200 Message-ID: <2825149.gOr3OGPAPz@thomas> In-Reply-To: <35199514.vTiSGuMgIC@thomas> References: <1596452291-25535-1-git-send-email-viacheslavo@mellanox.com> <5fc9b97b-3b02-1f9f-9acd-333a92585d58@solarflare.com> <35199514.vTiSGuMgIC@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] doc: announce changes to ethdev rxconf structure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 06/08/2020 14:39, Thomas Monjalon: > 05/08/2020 13:14, Andrew Rybchenko: > > On 8/5/20 11:49 AM, Viacheslav Ovsiienko wrote: > > > The DPDK datapath in the transmit direction is very flexible. > > > The applications can build multi-segment packets and manages > > > almost all data aspects - the memory pools where segments > > > are allocated from, the segment lengths, the memory attributes > > > like external, registered, etc. > > > > > > In the receiving direction, the datapath is much less flexible, > > > the applications can only specify the memory pool to configure > > > the receiving queue and nothing more. The packet being received > > > can only be pushed to the chain of the mbufs of the same data > > > buffer size and allocated from the same pool. In order to extend > > > the receiving datapath buffer description it is proposed to add > > > the new fields into rte_eth_rxconf structure: > > > > > > struct rte_eth_rxconf { > > > ... > > > uint16_t rx_split_num; /* number of segments to split */ > > > uint16_t *rx_split_len; /* array of segment lengths */ > > > struct rte_mempool **mp; /* array of segment memory pools */ > > > ... > > > }; > > > > > > The non-zero value of rx_split_num field configures the receiving > > > queue to split ingress packets into multiple segments to the mbufs > > > allocated from various memory pools according to the specified > > > lengths. The zero value of rx_split_num field provides the > > > backward compatibility and queue should be configured in a regular > > > way (with single/multiple mbufs of the same data buffer length > > > allocated from the single memory pool). > > > > > > The new approach would allow splitting the ingress packets into > > > multiple parts pushed to the memory with different attributes. > > > For example, the packet headers can be pushed to the embedded data > > > buffers within mbufs and the application data into the external > > > buffers attached to mbufs allocated from the different memory > > > pools. The memory attributes for the split parts may differ > > > either - for example the application data may be pushed into > > > the external memory located on the dedicated physical device, > > > say GPU or NVMe. This would improve the DPDK receiving datapath > > > flexibility preserving compatibility with existing API. > > > > > > The proposed extended description of receiving buffers might be > > > considered by other vendors to be involved into similar features > > > support, it is the subject for the further discussion. > > > > > > Signed-off-by: Viacheslav Ovsiienko > > > Acked-by: Jerin Jacob > > > > I"m OK with the idea in general and we'll work on details > > in the next release cycle. > > > > Acked-by: Andrew Rybchenko > > I agree we need to be more flexible with the mempools in Rx. > > Acked-by: Thomas Monjalon > Acked-by: Ferruh Yigit Applied Implementation will require more design discussions.