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 F2C90A00BE; Fri, 15 May 2020 17:10:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C24E81DAD5; Fri, 15 May 2020 17:10:15 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id A192B1DACE for ; Fri, 15 May 2020 17:10:13 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id DB192580221; Fri, 15 May 2020 11:10:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 15 May 2020 11:10:12 -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= t5sWO68IsQRxnzTvJtUTR2EsWBrJnVVgBs+8aGAh7vc=; b=oOVkvMxl+e87UKxh 7zZEZKuaOPtNg3OEt0ezi/zA/6UbWxJP3lpOY8qjNoirnb4zZ5kGUiO0VHfV0Gcc S83q4oGRtqa3srEbw4iPG84E8BozCApdTdHIrkEmDozFcoZgVXwuLCmLw/rP4EH9 feoK8UOqQnxWyqdVn5ERzBXe9FQl+nM1j2wdxWuf1F0T+xkWjilVXC2xU78/uO4M GYNFZ363XYRIm+AMRFMSiK0fg3aNlc3qrzGZ40Izmem4xjcRVuiwpLb8jkKNQ3N0 4TQw6g9Qjpj8hW/E69xXSgziUQH/YVgUnsm7vHjUvbJkRJVu67vUovBdaeyvmgi6 P/xlPA== 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=t5sWO68IsQRxnzTvJtUTR2EsWBrJnVVgBs+8aGAh7 vc=; b=3eujEGijFgm2VhCIy2GnQrAVqZiQjXidlSSm5GEAZVF2+39C4+oxDUUoZ 12TD3dBjSNkEXhr/zVeXABbGoWVNp2yYK9uNCJO5k3CTVD8gH6Ydw3bh3KtiyqeD bnhkmI/H3kKIBum7yYPmcOSzb9LE/jp0ETRaJk/GI6yW62GjSHmsYlGlDkBkocBr 6+V1ebqz1XGzdZ+VwThITLvhs1tJLFJprw1XHJIsglxb+wXuS/axP2C7uh35ro7Q /ot24ICLG28bmUribRKSALhlCRG8RLPd/8qOm8pKjIpKlB37EX0W5zXQCbpjS1KG R5YGqg7VsVM3yaDDHZFwJm05MrUxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleekgdekfecutefuodetggdotefrodftvf 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 45D7B328005D; Fri, 15 May 2020 11:10:10 -0400 (EDT) From: Thomas Monjalon To: Nithin Dabilpuram Cc: Olivier Matz , Jerin Jacob , 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 17:10:06 +0200 Message-ID: <16221090.5WZRyvrzyv@thomas> In-Reply-To: <20200515134420.GA9696@outlook.office365.com> References: <20200417072254.11455-1-nithind1988@gmail.com> <2214992.9fHWaBTJ5E@thomas> <20200515134420.GA9696@outlook.office365.com> 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 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. If you disagree with this new rule, you will have to give very good arguments.