From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0558A54AE; Wed, 19 Dec 2018 11:50:41 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7CAD42235B; Wed, 19 Dec 2018 05:50:40 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 19 Dec 2018 05:50:40 -0500 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=mesmtp; bh=jO9+alPVqo3AltwvvEqQHNo+3YQ0DKgqDGstIH4zycc=; b=fGzWpNQcSQTy IJ3o0GlC1UA8SwKu/dbL4Nert1O81jfS2UfLYtHYpxuXamXopm9hYTZp0bsmoDNi pSQrjOqOCge+5T/Bb+BNuOSzKmFfmsrH333o42wOppMYvhmfw1h3FE2iWcI53wDf HdQJhMztTdw9i1td7UTPBi45nNoMkhc= 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=jO9+alPVqo3AltwvvEqQHNo+3YQ0DKgqDGstIH4zy cc=; b=NlzGElA+gRrvoiG8Il7kbUQRgaboqN1t7vbFL9PQgT/+vrbLXsVyzNwXl 9g2Y0BSgWLhy6k/sPLtXjkKHRMax+EfeO1N4IiDbXEiM7Odlwhv34nHni8JDcclQ vYc52131sJippy1CMVnyuV2cADkgKp8oX260CI+cf0MwXj8sPVior6cX4h4WOBoO 4ACIM96N4FQKSe/ntFHd0n2zgwJJcayaifYVnOX+zp3iBvzwc6j+eb3K3g74SBQT KXV2s2/5t7u6DjHI5R/aLKWZAcpWNlfD8lLg+NqslzqqXTxsZiwveESsZmfyHbKA 4YPC02JPTK0ZLeX8h6e7Sh+uBJoPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejtddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffohhmrghinhepughpughkrd horhhgnecukfhppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiii gvpedt 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 8F4DB100E5; Wed, 19 Dec 2018 05:50:38 -0500 (EST) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: "Ananyev, Konstantin" , "Pattan, Reshma" , "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" , "Singh, Jasvinder" , "david.marchand@redhat.com" , "olivier.matz@6wind.com" , "techboard@dpdk.org" Date: Wed, 19 Dec 2018 11:50:37 +0100 Message-ID: <4890844.r5pLWrAf7n@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891268E816DB9@IRSMSX108.ger.corp.intel.com> References: <20181123165423.134922-1-jasvinder.singh@intel.com> <2721277.OGTcNX5HrL@xps> <3EB4FA525960D640B5BDFFD6A3D891268E816DB9@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition 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: , X-List-Received-Date: Wed, 19 Dec 2018 10:50:41 -0000 19/12/2018 11:47, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 18/12/2018 20:34, Dumitrescu, Cristian: > > > From: Ananyev, Konstantin > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > 18/12/2018 14:19, Dumitrescu, Cristian: > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > > 18/12/2018 12:18, Dumitrescu, Cristian: > > > > > > > > > > I replied in v3 that it should stay in rte_meter.h. > > > > > > > > > > You can include rte_meter.h in ethdev. > > > > > > > > > > > > > > > > > > OK, thanks Thomas, makes sense to me as well. > > > > > > > > > > > > > > > > > > > > > > > > > Thomas, > > > > > > > > > > > > > > > > I agree with your input, but just want to make sure we are on the > > > > same > > > > > > > page: > > > > > > > > > > > > > > > > Besides including rte_meter.h in ethdev (which you are fine with), > > we > > > > > > > would also need to include rte_meter.h in mbuf. > > > > > > > > > > > > > > > > Are you OK with this as well? > > > > > > > > > > > > > > Why do we need rte_meter.h in mbuf? > > > > > > > > > > > > > > > > > > > You probably looked at V2 only, but in V3 we have functions to > > set/get > > > > the color within the mbuf->hash.sched field. > > > > > > > > > > > > For space compression reasons, the mbuf->hash.sched stores the > > color > > > > on 8-bit variable, while for the outside world the set/get functions > > > > > work with the 32-bit enum type. We do same thing in other places in > > DPDK, > > > > such as rte_crypto_op, etc. > > > > > > > > > > So it's a different discussion. > > > > > We need to review this v3 and check how relevant this mbuf API is. > > > > > > > > > > If the API is accepted, yes the include should not be an issue. > > > > > > > > Personally, I don't think it is a good idea to add extra dependency for > > > > librte_mbuf. > > > > I'd prefer either to keep rte_color definition inside librte_mbuf, > > > > or move corresponding function definitions out of it. > > > > Konstantin > > > > > > Konstantin, > > > > > > As you see, the number of options is limited, and none of them is > > perfect: > > > > > > 1/ color enum in EAL/common/include: still my favorite, as it does not > > create any new library dependencies, and it is already used to store lots of > > similar generic items > > > 2/ color enum in rte_meter.h: results in creating new librte_mbuf > > dependency to librte_meter > > > 3/ color enum in rte_mbuf.h: results in creating new librte_meter > > dependency to librte_mbuf (yes, currently librte_meter does not depend on > > librte_mbuf) > > > > > > Personally, I can live with any of these options. > > > > > > Thomas, > > > > > > It would be good to have your input as well, Reshma just sent V4 > > implementing your proposal based on having the color enum defined in > > rte_meter.h, which gets included into rte_mbuf.h. > > > > We need a decision from Olivier, mbuf maintainer. > > > > > We need to make progress for RC1 deadline. > > > > I'm afraid 19.02 is not the right release to change the mbuf. > > This kind of decision usually takes several weeks. > > Cc the technical board to get more opinions. > > > > Hi Thomas, > > The only change we are planning to do on the mbuf is reformatting of the sched field, according to the deprecation note that was already acked by Olivier and many others: > http://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst#n52 > > We are planning to send V5 that should simplify the solution and avoid any such issues. Specifically, what we are going to do in V5 is: > 1/ Make sure the only mbuf changes are related to the reformatting of the sched field, precisely implementing the above deprecation note; > 2/ Include rte_meter.h into some ethdev headers, which you already agreed with > 3/ Avoid adding any header to librte_eal/common/include > > Are you OK with this? > > Hopefully this should remove any roadblocks and any further delays for this patch set. Yes I am OK. Obvioulsy, I would be more confortable if having an ack from Olivier.