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 0F99CA04B7; Wed, 14 Oct 2020 09:17:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A8D751DC67; Wed, 14 Oct 2020 09:17:48 +0200 (CEST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) by dpdk.org (Postfix) with ESMTP id 3EDBF1DC63 for ; Wed, 14 Oct 2020 09:17:47 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 8BBB130F; Wed, 14 Oct 2020 03:17:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 03:17:43 -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= wiXqXFYoRjeWiVwddRHjrW+jvsN9rEmAlijPlVN54UA=; b=YLTNDpAgECZ0jEO4 Bl3vA2e0f68KbpT41ILxMnrogNlCGVwkm+J1O2QT50jElMmq1MRx8mHOGnwXGUS9 1wajZHULGa4zsP2cFnpJybIjIdX/HS4co6vkSRPcaTZe9ku55IGJ/3fne5tgw5FC X1LKzvwR6OV7SnDiuhjcu11oc5eI/8uKb0M/WAcuUX+TaGO7E+s70N4J/poeuq9h hfCxTvD9iJfBFU1dUhCZlZOrgPSclSVYesCuln5if6XuA+yq15xEP/zceHIebr8d M9tPolAt2VkD+MmoCqMQXRNBCnteXH5xjptLX8WBGHfwEEvgM0/bnd8eCmfQoC3t jxBH6g== 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=wiXqXFYoRjeWiVwddRHjrW+jvsN9rEmAlijPlVN54 UA=; b=VYneRsEsggCC2C/YIZBP75Uv3ilFZjCwTbZINbTb3sBqRaAc0oqemP3VX ZFTeYxQKTKV2Ymf9NXQ6aseu5bYgAoOVZrHYKIUzr+C+SznK/Zoj8cX29O+ddaX9 SzrRx332/YRrRAbT5f1fr4ckfCuIPN9Ofb5LmQWPeKtqU4Cb2kszOQWCX0ptuB1h FaMh1jbEDxgO/CWVGjzkc/YCpI/iIsUXoj1f8DND9QAl1smN2RNh9Vi+MdYJenN3 6Tvcsg07ua52CGiphcu619I/lwGUXPs/5vr85IaDpag+p9hG5r7maPLsHaFK2LMF FVGyqcu5y7mDf+uDCss4IyxhsPfHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedtgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf 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 8880F3280060; Wed, 14 Oct 2020 03:17:39 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Slava Ovsiienko , Andrew Rybchenko , "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 , Konstantin Ananyev Date: Wed, 14 Oct 2020 09:17:38 +0200 Message-ID: <5915060.dkjAuQWYH0@thomas> In-Reply-To: <90d1f9d6-9183-838b-2cf8-d276aa4f42b1@intel.com> References: <90d1f9d6-9183-838b-2cf8-d276aa4f42b1@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 13/10/2020 23:59, Ferruh Yigit: > On 10/12/2020 10:56 AM, Slava Ovsiienko wrote: > > 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 places to specify > > the pool - in rx_queue_setup() and in the config structure. So, we should > > implement some checking (if we have offload flag set we should check > > whether mp parameter is NULL and segment descriptions array pointer/size > > is provided, if no offload flag set - 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? > > I think decision was given with the deprecation notice which already says > ``rte_eth_rxconf`` will be updated for this. > > With new API, we need to create a new dev_ops too, not sure about creating a new > dev_ops for a single PMD. You should not view it as a feature for a single PMD. Yes, as always, it starts with only one PMD implementing the API, but I really think this feature is generic and multiple NICs will be able to support this offload. > For the PMD that supports this feature will need two dev_ops that is fairly > close to each other, as Andrew mentioned this is a duplication. > > And from user perspective two setup functions with overlaps can be confusing. > > +1 to having single setup function but update the config, and I can see v5 sent > this way, I will check it. > > > > Now I'm updating the existing version on the patch based on rx_queue_ex() > > and then could prepare the version for configuration structure, > > it is not a problem - approaches are very similar, we just should choose > > the most relevant one. > > > > With best regards, Slava