From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DA73BA0542; Mon, 30 May 2022 18:46:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 963FC40689; Mon, 30 May 2022 18:46:11 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 930BA400D6 for ; Mon, 30 May 2022 18:46:10 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3C46C5C006C; Mon, 30 May 2022 12:46:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 30 May 2022 12:46:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1653929170; x= 1654015570; bh=HNJOhB/VZpk1J0HhppfMjKy+8x+P7VBaa8+Fqm5Zry8=; b=y TN6/gGU0zGVrB67+P11/LBGirbJVZsvSdV9H6UWPV1alaeiw7gy2II2BGloUtB6H dsVDlWL6VHNXs3kUcDpmLnhRwLWG24jWA3UpkDoBJsmTpbi1ogCoZ86MieutIV8B 8Uwm+p5NScluU+Rwq5pp+0ae5SfnFmtLj4OUamOCfqvmg/iVuR/NetCHxfyPo0eZ YOCnJ8V0+U0fLE7N2b6vnd4Yrtu7JB4pfhjnCw3GFiAawABGETWErdmfnqtr8f+c FT7J07TzBw4kMIwAXAHBcznINbQcz35ZG55wf3fCRwD3FzpHjbM1LjmZS5GEBHaY n5QUHPx97OloYl3J2h2VQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1653929170; x= 1654015570; bh=HNJOhB/VZpk1J0HhppfMjKy+8x+P7VBaa8+Fqm5Zry8=; b=b uPcJOKhikNu06jt1WmdLQ+3GZ7kw4CHHxGOjAFoM1OfdaGKHhWC83/eIBE8xwL9S yv8sEx1MWdHAuxjNvBn1JjHIAql0IoQouoTW4pY2oijEENLAdS4Q1kMM4V9T1cX5 8dn6kFy0W/ev4oXdHNEZxgmWoR7+t94SJvuDnxX/H+SMhggcMuAMp50P8Yb2xvBZ ZNUA0CILe7/RcIjcOoDv3EXiXFeCoQLHuUV/rzXqsf4lttb0Jmta1MatKc7bvoKw 1VeoLbgqMVv6jgRjbmfmVUU2HVioqh04OsZ2pGOP9waUr566+4y8K/Vs3FzyK7Z7 DPqTp+3+PpuVvwXxaYMxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrkeeigddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 May 2022 12:46:08 -0400 (EDT) From: Thomas Monjalon To: Xiaoyu Min Cc: Ori Kam , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org Subject: Re: [RFC 1/2] ethdev: port flags for pre-configuration flow hints Date: Mon, 30 May 2022 18:46:05 +0200 Message-ID: <7384952.EvYhyI6sBW@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org We were waiting for a v2 of this patch. More comments below. 07/04/2022 07:30, Xiaoyu Min: > The data-path focused flow rule management can manage flow rules in more > optimized way then tranditional one by using hits provided by hits -> hints > application in initialization phase. > > In addition to the current hints we have in port attr, more hints could > be proivded by application about it's behaviour. it's -> its > One example is how the application do with the same flow: flow -> flow rule ? > A. create/destroy flow on same queue but query flow on different queue > or queue-less way (i.e, counter query) > B. All flow operations will be exactly on the same queue, by which PMD > could be in more optimized way then A because resource could be > isolated and access based on queue, without lock for example. > > This patch add flag about above situation and could be extanded to cover extended > more situations. > > Signed-off-by: Xiaoyu Min > --- > +/** > + * The flags of rte flow port > + */ > +enum rte_flow_port_flag { Don't use enum for bit flags. > + /** > + * All flow operations for one specified flow will _strictlly_ happen I guess you mean "for a given flow rule" strictlly -> _strictly_