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 7E700A04B6; Mon, 12 Oct 2020 18:53:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0B4091D94E; Mon, 12 Oct 2020 18:53:00 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 93A551D94C for ; Mon, 12 Oct 2020 18:52:58 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 31C89580377; Mon, 12 Oct 2020 12:52:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 12 Oct 2020 12:52:55 -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= 3QLZTL8nRsk1GBKF/elG0pJKxzbyv56lgjq9MaUJRBA=; b=kAtnWNxuDGpberXj wFjWCnGoHh9+vsbA30t6MrSPqhi196UhlFojTFg5TvJEd9IDVzWZy8YAd7jPCXBh qMhMJSckK8z9g4KDXlgVYDigJm/eCwMy27WglfrIQR5HH3aEnm6XkBKYL7xzaOPW cT22WCCa1nnuF3PGT13Gl00mmFRQhjOFLbdJioZQh3JTV1/OtrASxs3fCrWB4YBQ VfEOTGjPVUyem+W+Zi+HO6MSNZ9QUWFE1eYAaUPEpvYguAuQaIvl5LALktz+KcV4 OUKCLIKNyaZAlDewpGeA1yjloJK39mfkXnAIDpg5yKiFvaMxW9wFB950qDDfb54v LJyiWA== 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=3QLZTL8nRsk1GBKF/elG0pJKxzbyv56lgjq9MaUJR BA=; b=T7+LBIfeNOojmRU5J1qYCG1A76qJgALbA2uNz56e5rRU2EIr4Rr24ThrV mGswZRxgMUyMADLkeGk6+knO9AMXgqijR6Wj3qiL3cpyux04f+sywIevzA2HFhSA tyZ8V3lHVVkT+UAwMFc4p3N5JV2/bxp70PzTtLftoftd2XucCuy72l+al0Kt/NYx Q+TY1oeRChSWkThiz5FS3EH+CdX3OzqFUaGnt9QMe0z6m5MISVYYejFoW3IOa2Tq W24t/NF6ArUj9S3JXhXFmnLtHN3g4DEJY+8zQ0AyWBCsacjiXzkrSho/MO84yi62 +eOasxesDhLoZaKjBxCVprgWPY6JQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheejgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 97B143064682; Mon, 12 Oct 2020 12:52:52 -0400 (EDT) From: Thomas Monjalon To: Slava Ovsiienko , Andrew Rybchenko , "Yigit, Ferruh" , "Ananyev, Konstantin" Cc: "dev@dpdk.org" , "stephen@networkplumber.org" , Shahaf Shuler , "olivier.matz@6wind.com" , "jerinjacobk@gmail.com" , "maxime.coquelin@redhat.com" , "david.marchand@redhat.com" , Asaf Penso Date: Mon, 12 Oct 2020 18:52:50 +0200 Message-ID: <1847409.7NbrJBXJ13@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] 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" 12/10/2020 17:56, Ananyev, Konstantin: > > From: Ananyev, Konstantin > > > > 12/10/2020 11:56, Slava Ovsiienko: > > > > > We have two approaches how to specify multiple segments to split = Rx > > > packets: > > > > > 1. update queue configuration structure 2. introduce new > > > > > rx_queue_setup_ex() routine with extra parameters. > > > > > > > > > > For [1] my only actual dislike is that we would have multiple pla= ces > > > > > to specify the pool - in rx_queue_setup() and in the config > > > > > structure. So, we should implement some checking (if we have offl= oad > > > > > flag set we should check whether mp parameter is NULL and segment > > > > > descriptions array pointer/size is provided, if no offload flag s= et - we must > > > check the description array is empty). > > > > > > > > > > > @Thomas, @Ferruh: I'd like to hear what other ethdev maintainers > > > > > > think about it. > > > > > > > > > > Yes, it would be very nice to hear extra opinions. Do we think the > > > > > providing of extra API function is worse than extending existing > > > > > structure, introducing some conditional ambiguity and complicating > > > > > the parameter compliance check? > > > > > > > > Let's try listing pros and cons of each approach, so we can conclud= e. > > > > > > > > 1/ update queue config struct > > > > > > > > 1.1 pro: keep same queue setup function > > > > 1.2 con: two mempool pointers (struct or function) > > > > 1.3 con: variable size of segment description array > > > > > > > > 2/ new queue setup function > > > > > > > > 2.1 con: two functions for queue setup > > > > 2.2 pro: mempool pointer is not redundant > > > > 2.3 pro: segment description array size defined by the caller > > > > > > > > What else I'm missing? > > > > > > > > > > My 2 cents: can we make new (_ex) function to work for both original = config > > > (1 mp for all sizes, no split) and for new config (multiple mp, split= allowed)? > > > Then in future (21.11?) we can either get rid of original one, or eve= n make it > > > a wrapper around all one? > > > Konstantin > >=20 > > Yes, actually the mlx5 PMD implementation follows this approach - > > specifying the segment description array with the only element > > and zero size/offset provides exactly the same configuration as existing > > rte_eth_rx_queue_setup(). > >=20 > > Currently I'm detailing the description (how HEAD_ROOM is handled, wha= t happens > > if array is shorter the the buffer chain for segment of maximal size, t= he zero segment > > size means follow the value deduced from the pool and so on). > >=20 > > So, may we consider this point as one more "pro" to setup_ex approach ?= =F0=9F=98=8A >=20 > From my perspective, yes. > It is sort of more gradual approach. > I expect it would be experimental function for some time, > so we'll have time to try it, adjust, fix, etc without breaking original = one. I like the wrapper idea. Is it possible to call rte_eth_rx_queue_setup_ex() from rte_eth_rx_queue_setup() using a rte_eth_rxseg object on the stack?