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 901EFA04DB; Thu, 15 Oct 2020 00:14:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1E67D1D60E; Thu, 15 Oct 2020 00:14:04 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id F37FD1C20D for ; Thu, 15 Oct 2020 00:14:02 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9B2CF5C01C9; Wed, 14 Oct 2020 18:14:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 18:14: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=fm2; bh= 955HB7iiaXLZirnzN3nfBBJvygcPEXbfRp62bpvctoE=; b=skxQ/M1wqEEkDyR5 WnvYz3P7EGU8/EvHPzEY2+3ae5oPZJMZyEmWMmnjOCQDGb8zK4ql1Xwm11mhIPtL MOgBXgH/ynBh+iYShItKsb5n+6wcJWbh0BZty+WvmM44FAQc1aCr2BzcvG4gC9mc 1w32nwPckgRPlJTAOOwvWxwletRamweDHCLWIsM5YT3K9qaRbRFavh6lyr+xE1rX EqE/ux/vPWrt/yAFL3ZsFa46DJwjrv8unFo5XlEErUfDN712yGzpWQ0L/HIfKceF cFjZQDjHhF62PezTW1wy3LkOtOsOPOtw2HhBg7x3JmNOoW6+q1AqS1molM5OKPNe LkGbEA== 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=fm1; bh=955HB7iiaXLZirnzN3nfBBJvygcPEXbfRp62bpvct oE=; b=KjHj2tg/IoTkTXOgSWB9P4WmAW3683DTzeACykcIsADKMFJ9sYswlFs6x hv/FSUM7aT8ob/9xMTHYfUXVXxkLeJChrDo5cITtawxulDG4mWB191vuUKMRN28Q Tb4jAXAvXvESlrMpr1QOkbAAPr7Fw52WZt1zV+WKM/S9PPuViljVR/F5YYc+OBA+ AMY+DjwHhOblsVw56eUpUktsnR3U+xmqKwaGCzX3qguXRttW8cBz0yxYgo0Ly99+ hOLIt0jYiSh0x7fFe2Gdmaoi51rKjytUxlaGB3k4fsuLFoSUsKn7pBT7fQ5/KvLZ 7RYRzeBqNhtglzwT7y85mFrKVgnFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedvgddtjecutefuodetggdotefrodftvf 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 A2359306467D; Wed, 14 Oct 2020 18:13:59 -0400 (EDT) From: Thomas Monjalon To: Viacheslav Ovsiienko Cc: dev@dpdk.org, stephen@networkplumber.org, ferruh.yigit@intel.com, olivier.matz@6wind.com, jerinjacobk@gmail.com, maxime.coquelin@redhat.com, david.marchand@redhat.com, arybchenko@solarflare.com Date: Thu, 15 Oct 2020 00:13:57 +0200 Message-ID: <178080479.kZy0JhJW7U@thomas> In-Reply-To: <1602699122-15737-2-git-send-email-viacheslavo@nvidia.com> References: <1602699122-15737-1-git-send-email-viacheslavo@nvidia.com> <1602699122-15737-2-git-send-email-viacheslavo@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split 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" 14/10/2020 20:11, Viacheslav Ovsiienko: > The DPDK datapath in the transmit direction is very flexible. > An application can build the multi-segment packet and manages > almost all data aspects - the memory pools where segments > are allocated from, the segment lengths, the memory attributes > like external buffers, registered for DMA, etc. > > In the receiving direction, the datapath is much less flexible, > an application can only specify the memory pool to configure the > receiving queue and nothing more. In order to extend receiving > datapath capabilities it is proposed to add the way to provide > extended information how to split the packets being received. > > The following structure is introduced to specify the Rx packet > segment: > > struct rte_eth_rxseg { > struct rte_mempool *mp; /* memory pools to allocate segment from */ > uint16_t length; /* segment maximal data length, > configures "split point" */ > uint16_t offset; /* data offset from beginning > of mbuf data buffer */ > uint32_t reserved; /* reserved field */ > }; > > The segment descriptions are added to the rte_eth_rxconf structure: > rx_seg - pointer the array of segment descriptions, each element > describes the memory pool, maximal data length, initial > data offset from the beginning of data buffer in mbuf. > This array allows to specify the different settings for > each segment in individual fashion. > rx_nseg - number of elements in the array > > If the extended segment descriptions is provided with these new > fields the mp parameter of the rte_eth_rx_queue_setup must be > specified as NULL to avoid ambiguity. > > There are two options to specifiy Rx buffer configuration: > - mp is not NULL, rx_conf.rx_seg is NULL, rx_conf.rx_nseg is zero, > it is compatible configuraion, follows existing implementation, > provides single pool and no description for segment sizes > and offsets. > - mp is NULL, rx_conf.rx_seg is not NULL, rx_conf.rx_nseg is not > zero, it provides the extended configuration, individually for > each segment. > > The new offload flag RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT in device > capabilities is introduced to present the way for PMD to report to > application about supporting Rx packet split to configurable > segments. Prior invoking the rte_eth_rx_queue_setup() routine > application should check RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag. > > If the Rx queue is configured with new settings the packets being > received will be split into multiple segments pushed to the mbufs > with specified attributes. The PMD will split the received packets > into multiple segments according to the specification in the > description array: > > - the first network buffer will be allocated from the memory pool, > specified in the first segment description element, the second > network buffer - from the pool in the second segment description > element and so on. If there is no enough elements to describe > the buffer for entire packet of maximal length the pool from the > last valid element will be used to allocate the buffers from for the > rest of segments > > - the offsets from the segment description elements will provide > the data offset from the buffer beginning except the first mbuf - > for this one the offset is added to the RTE_PKTMBUF_HEADROOM to get > actual offset from the buffer beginning. If there is no enough > elements to describe the buffer for entire packet of maximal length > the offsets for the rest of segment will be supposed to be zero. > > - the data length being received to each segment is limited by the > length specified in the segment description element. The data > receiving starts with filling up the first mbuf data buffer, if the > specified maximal segment length is reached and there are data > remaining (packet is longer than buffer in the first mbuf) the > following data will be pushed to the next segment up to its own > maximal length. If the first two segments is not enough to store > all the packet remaining data the next (third) segment will > be engaged and so on. If the length in the segment description > element is zero the actual buffer size will be deduced from > the appropriate memory pool properties. If there is no enough > elements to describe the buffer for entire packet of maximal > length the buffer size will be deduced from the pool of the last > valid element for the remaining segments. > > For example, let's suppose we configured the Rx queue with the > following segments: > seg0 - pool0, len0=14B, off0=2 > seg1 - pool1, len1=20B, off1=128B > seg2 - pool2, len2=20B, off2=0B > seg3 - pool3, len3=512B, off3=0B > > The packet 46 bytes long will look like the following: > seg0 - 14B long @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 > seg1 - 20B long @ 128 in mbuf from pool1 > seg2 - 12B long @ 0 in mbuf from pool2 > > The packet 1500 bytes long will look like the following: > seg0 - 14B @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 > seg1 - 20B @ 128 in mbuf from pool1 > seg2 - 20B @ 0 in mbuf from pool2 > seg3 - 512B @ 0 in mbuf from pool3 > seg4 - 512B @ 0 in mbuf from pool3 > seg5 - 422B @ 0 in mbuf from pool3 > > The offload RTE_ETH_RX_OFFLOAD_SCATTER must be present and > configured to support new buffer split feature (if rx_nseg > is greater than one). > > 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 with preserving compatibility > with existing API. > > Signed-off-by: Viacheslav Ovsiienko A large part of this commit log can be dropped because redundant with the doxygen comments. Acked-by: Thomas Monjalon