From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:8fkrX6_xENiWMIuUaUa7W5GGHONj4Kb3mMav6ylS2CCGs9oGx6Yd3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkedtgdehhecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih
iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho
nhdrnhgvth
X-ME-Proxy: <xmx:8fkrX6s9pA8Oa2ux33yofqNM8ZFxEPdkp0QHXvaEKd9FOP1Mcg0krQ>
<xmx:8fkrXwA8WlOF0GtjFCVnLZz32Idslt2hxqvMciO-wrUtojye-chcCQ>
<xmx:8fkrXyf4NiTBxO04Iu6r22I0nYQdhz8EC8rPX-5A0qRXyY2sIvriOQ>
<xmx:8vkrX4gkEEbZWMj5gpz72HVB2HKfk1JvYZ6-sge8R0T-8McsZUwFtg>
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 <thomas@monjalon.net>
To: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
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 <arybchenko@solarflare.com>
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 <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
Sender: "dev" <dev-bounces@dpdk.org>
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 <viacheslavo@mellanox.com>
> > Acked-by: Jerin Jacob <jerinjacobk@gmail.com>
>
> I"m OK with the idea in general and we'll work on details
> in the next release cycle.
>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
I agree we need to be more flexible with the mempools in Rx.
Acked-by: Thomas Monjalon <thomas@monjalon.net>