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 BDB22A0351; Thu, 6 Aug 2020 14:39:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9D6102BF2; Thu, 6 Aug 2020 14:39:15 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id B47102BF1 for ; Thu, 6 Aug 2020 14:39:14 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 5CE915802AD; Thu, 6 Aug 2020 08:39:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 06 Aug 2020 08:39:14 -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= Vvn3suI81ku59uA1WJFXTaQWkpms8KB98y0wxr6jzis=; b=mx1H49lzVpglREN5 9+zunsHUmDhOoLH+1nbTLD90/kBReMJpChdx7i5cPbi/t8cw/24pWnRSrP1FuvYy 5C4iRUDqG6eL6RMKrkORhnphkOps8DJf85t2RKXl3u+QmB9ds1U7tDFFwHThZodd OVKA3uNoTRA3N5J2oXFWRKOd2THAl38GxwDh5BuEhFkq2gVgzpBk3imUgbPHNMKq CSHRFrKDvl/VS8LlizIADYJqStSMFbKsmTlDZV53f5+Fj9maCMlpfLqn62akum6n HVgr/OrnuL7jNMZ5XSdzTPdjaDNaPVhX/21O9KQqm4WPHGBVDF/VGLs+BtOde1UO NrFGgA== 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=Vvn3suI81ku59uA1WJFXTaQWkpms8KB98y0wxr6jz is=; b=W0bStAeUXHrzivqjaSgXbS2S/4mbApr6hW634qBcqkHtadTj6f7SDuV6p 22QTNIoH/ujj+tgGjYvWgpYZsYuLup3VeXZcbtTGh8FMA2c4A4AzfdWcSf4Fmycw bTmO1Ab41/M749ideS/nzf7i/1EMp1agYcNXHJN09PzYr+r6/UB0s1E+Kg4F9kDt WCCG0NL+obZvTTlTSAol+H86TJd/GAK9VedqFKH6kfI3CZWgNXQmnEdoRHG7OctC RLjGKWPJBLBKVA1Q7a4laNLmhRixamJSxfYyzSe21X31l1EOOL0v0wiSxSqmxtZO VvVsRpxvewwgIeuwo/j/0sYD1/QNA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkedtgdehhecutefuodetggdotefrodftvf 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 A5FE1328005D; Thu, 6 Aug 2020 08:39:12 -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 14:39:11 +0200 Message-ID: <35199514.vTiSGuMgIC@thomas> In-Reply-To: <5fc9b97b-3b02-1f9f-9acd-333a92585d58@solarflare.com> References: <1596452291-25535-1-git-send-email-viacheslavo@mellanox.com> <1596617395-29271-1-git-send-email-viacheslavo@mellanox.com> <5fc9b97b-3b02-1f9f-9acd-333a92585d58@solarflare.com> 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" 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