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 64166A00BE; Fri, 15 May 2020 18:52:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 40FF21DB03; Fri, 15 May 2020 18:52:29 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 0867D1DAFD for ; Fri, 15 May 2020 18:52:28 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 2C2FE580116; Fri, 15 May 2020 12:52:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 15 May 2020 12:52:27 -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= mFhSmjx2FuZ29U2uNwigfFjldnUxEBcKSu8lVjFf/TU=; b=ZhsgSHINRYj/4tNm aiOuX6O5NQFPNfpDCCfR0Iv01X2ybJb52sF8WaUUx2JRCWbEFmEKwQ1sgS8kTtQv KDo8mYIyt4gtHlwh+9Me4AZNPIltiabrSHKTkMAu3mW+WmLdwr/k9eE2dgmxRG9U qDVZA/0x4BxYvSQb1EiOeNu9niq5DBhfuL4LaUuCIaI0+NuZ2H3yPecRqkVwZjK1 7F2wWW/MBdmqxby1Ewz+OsI9ReKrtz9wTgLJPfnncHgqv6zgYatsoDMgGqgtWoCb lFzsRASPrg/Vx4U54hGnrtDPfP7o8W5d70gYL6UjRmfj+iqJNOtkr7zQnwjGrSIw F9B97w== 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=fm2; bh=mFhSmjx2FuZ29U2uNwigfFjldnUxEBcKSu8lVjFf/ TU=; b=ElR6g2XA/6BweMal2TM6Wa2/dSiD9OFjy1iAYy6MWs9lF3Kbso7mzdnJI /D8NyGskTbHm6+f3r+SePjIMd1xaoJIl5mpX9tUWzndXmljgPYzWH894Pp0UpX0y 2noZ3vzO7i7UiFDwmLUSAwNz+K9RxNPbfwEDyzR9nC19HFtivdAYAHwW28qlr79y jFzP2TZbppZXuvQHzzfNOHgGUzAR0DppnR5ZDUQWI0b1hGQ8Wd01AXj4+r7mReSp l0HicPMpPNYraJppXRk7C1Z2P3MCU6dSixdsarDD+Y+/V1XdHeedz0a2IU/yQUiH gGALQd6tp2/Mr/xjRRBXT45gBoJrg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleekgddutdefucetufdoteggodetrfdotf 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 8A9A63280059; Fri, 15 May 2020 12:52:24 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Nithin Dabilpuram , Olivier Matz , Nithin Dabilpuram , Ferruh Yigit , Andrew Rybchenko , Ori Kam , Cristian Dumitrescu , Anatoly Burakov , John McNamara , Marko Kovacevic , dpdk-dev , Jerin Jacob , Krzysztof Kanas Date: Fri, 15 May 2020 18:52:23 +0200 Message-ID: <2370081.kdYZ1jHi8b@thomas> In-Reply-To: References: <20200417072254.11455-1-nithind1988@gmail.com> <16221090.5WZRyvrzyv@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/3] mbuf: add Tx offloads for packet marking 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" 15/05/2020 18:26, Jerin Jacob: > On Fri, May 15, 2020 at 8:40 PM Thomas Monjalon wrote: > > 15/05/2020 15:44, Nithin Dabilpuram: > > > On Fri, May 15, 2020 at 03:12:59PM +0200, Thomas Monjalon wrote: > > > > 15/05/2020 12:08, Nithin Dabilpuram: > > > > > On Thu, May 14, 2020 at 10:29:31PM +0200, Olivier Matz wrote: > > > > > > I don't see any better approach than having a mbuf flag. However, I'm > > > > > > still not fully convinced that a dynamic flag won't do the job. Taking > > > > > > 3 additional flags (among 18 remaing) for this feature also means that > > > > > > we have 3 flags less for dynamic flags for all applications, even for > > > > > > applications that will not use this feature. > > > > > > > > > > > > Would it be a problem to use a dynamic flag in this case? > > > > > Since packet marking feature itself is already part of spec, > > > > > if we move the flags to PMD specific dynamic flag, then it creates a confusion. > > > > > > > > > > It is not the case of a custom feature supported by a specific PMD. > > > > > I believe when other PMD's implement packet marking, the same flags will > > > > > suffice. > > > > > > > > A dynamic flag is not necessarily PMD-specific. > > > > It is just avoiding consuming bits if the feature is not used by the application. > > > > We must move more existing flags and fields to be dynamic. > > > > > > > > In general, all new flags and fields in mbuf should be dynamic. > > > > And a work must be done to move existing stuff to free more space > > > > for more dynamic features. > > > > > > My bad, I thought dynamic flags can only be used for PMD specific thing. > > > > > > There is however a cost of using dynamic flag which I think should be avoided > > > for DPDK spec defined offloads, though it's fine for PMD specific things. > > > > > > Dynamic offload flags causes application and PMD to use non constant offset > > > or shift which are looked up at init, instead of having a constant shift or > > > offset. This indirection costs some cycles due to extra loads in fast path. > > > > Yes there is a cost. We described it quite clearly last year. > > The default rule is now to add new flags and fields as dynamic. > > In case the rule was not clear, I will send a patch to insert some > > notes in the code and the doc. > > Yes. Please send a patch to document the rule. That makes life easy > for everyone to make a boolean decision. Yes, I will work on it. > Here is the comment from mbuf: support dynamic fields and flags commit > when accepted this patch. > > " The typical use case is a PMD that registers space for an offload > feature, when the application requests to enable this feature. As > the space in mbuf is limited, the space should only be reserved if it > is going to be used (i.e when the application explicitly asks for it). > " OK, there is probably a documentation gap. > If you are pushing this feature to dynamic mbuf filed then rte_tm > subsystem needs to register dynamic field > not the PMD as the feature is part of rte_tm spec. Is there a function in rte_tm which initializes or configure the feature? > > If you disagree with this new rule, you will have to give very good arguments. > > What would the definition of a good argument? as the same logic can be > implemented with dynamic vs > static at the cost of dynamic indirection. I think the only exception to add a static flag or field is to demonstrate how basic is the feature. But I think all basic features are already integrated for years.