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 1144D41B9F; Wed, 1 Feb 2023 14:37:14 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 97B1C4021F; Wed, 1 Feb 2023 14:37:13 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 054694021D for ; Wed, 1 Feb 2023 14:37:12 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 60E1C5C00AF; Wed, 1 Feb 2023 08:37:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 01 Feb 2023 08:37:12 -0500 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=fm3; t=1675258632; x= 1675345032; bh=WQOlCH+AIOAdSSH5Q2YyFyNnmjKRcUO4SCeVWOESq14=; b=T YBK4FcmDraMqHfyNXfrn1KyNygQemC5p/mQoGeZ9WebpwXwPO/mloaHR/uxCsCAy b7g3ukJGrrRVhWO3Rey5zRvk4E2Zu9DBGhI9Jt7d5+UVkyYGMyl/UNvKbkVRGea2 cy71JHFLzsrITnwqLTqxQfk/nXHGkzQ+I/SkwjaBzCJaweq/Gbh2RR5Rqjk2svDF eZoqI5CtzOOVjMfnIwq/7k9UmmBGNWyWuGKwuxABqXnL4g4gYSMl6XuphhnE9ttR uE2wFjSP3xOQ3I3R7jl1hPAqIUyLqEjtKE6lK3OBPlvsrly62T/KAHA3O6hp7N3j JzEwtwqjh7cA1GuBXd04A== 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=fm3; t=1675258632; x= 1675345032; bh=WQOlCH+AIOAdSSH5Q2YyFyNnmjKRcUO4SCeVWOESq14=; b=D oD7Vyh5hNYx91g66CzupWAluw52njFQzDAc5BmEbPQrTWYB7UBsYeRLr9jP7DXsI sKhgn9tqDLqI0sBqNInx8u+K+FwvXakAQ8x/erkN4YIDqXSAQ1KuNV2WfFY0USP6 1UgjPY2rR8v9/aTDjNtnmaRfjXuvRC2qBd5/K+s8dG2ElcaHDBPjp75Ry2qAYakH ilkeRQf+Lb0DN8S9iq2BZ0x5jwz7uY0HfGdgzf3SzD4ci/ph7xTmdwyyyepd0vpw 7TF5fxQWYWMhO3SXdszm9Pjm6cu+3q8GwinKo4AEOh6Ag/Db8QvsiEQIzhEmnZQ/ D/qic4lQ1jqzImh9LMEPg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefiedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Feb 2023 08:37:10 -0500 (EST) From: Thomas Monjalon To: Ivan Malov Cc: Rongwei Liu , Matan Azrad , Slava Ovsiienko , Ori Kam , Aman Singh , Yuying Zhang , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh Subject: Re: [PATCH v7] ethdev: add special flags when creating async transfer table Date: Wed, 01 Feb 2023 14:37:09 +0100 Message-ID: <2807682.yaVYbkx8dN@thomas> In-Reply-To: References: <20221114115946.1074787-1-rongweil@nvidia.com> <1707507.QkHrqEjB74@thomas> 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 01/02/2023 12:50, Ivan Malov: > On Wed, 1 Feb 2023, Thomas Monjalon wrote: > > 31/01/2023 06:30, Ivan Malov: > >> I still hope community will comment on the possibility to > >> provide a hint mechanism for always-the-same match items, > >> with the perspective of becoming more versatile. > > > > Any hint could be imagined. > > But please keep this in mind: a hint is *not* a matching criteria, > > for the simple reason that a hint can be ignored by the PMD. > > So you cannot use a hint to avoid specifying a match item, > > but you could use a hint to specify that an item is the same > > for all the rules of a table. > > Reading the same thought expressed in your words, the penny drops. > So, a hint then. But even not being a match criterion itself, it > is still confined to knowledge about a too special particularity. > If one needs to add similar hints for other aspects of matching, > they will have to add more and more bits to this namespace. > So why at all detach the namespace of hints from such of > the match items? A more generic solution might be needed. The hints are not necessarily related to the matching. That's why it is more flexible to have separate definitions. > In another email of yours, [1], you suggest that documentation be > improved. But it seems that addressing the "fixed match" issue > described by Ori (in the quote) could be that "more generic" > approach. For example, if one added "always_fixed_spec" bit > to struct rte_flow_item, this bit could be taken into > account by PMD in rte_flow_pattern_template_create(). > When it has spotted this bit for item ANY_VPORT, > it will treat it the way this "specialise" hint > does, collecting the same upfront knowledge. > > Yes, I do acknowledge that encountering such a bit in > a regular/sync flow parsing is irrelevant, but this > is just a general idea and not the final proposal. Yes it does not have sense outside of template table. > Also, in mail [2], Ori talks about separate pipelines > for ingress and egress. That sheds some light on this > hint, thanks. On the one hand, yes, vendors do tend > to have separate pipelines for this, this and this, > but, on the other hand, assuming this particular > separation of pipelines and making a customised > hint for it might not be quite generic. It is > that special particularity which I am talking > about in the first paragraph of my response. > > So why not combine addressing "fixed match" items > and solving the problem of this "direction" hint? I agree we should try to better address templates with some fixed matching items, but we could still need to have some hints for other kind of optimizations. > Again, I can't come up with an immediate example > of how precisely this could be useful, but since > DPDK strives to being as much generic/neutral as > possible, then why not consider this? I agree the hints may be quite vendor-specifics, but they are optional and does not hurt vendors not implementing them. For applications supporting many drivers, they can use some hints without losing portability. So I don't think such approach is against genericity or neutrality, it is just bringing some flexibility for the best performances. And in DPDK, the first priority is the performance. > [1] https://mails.dpdk.org/archives/dev/2023-February/260667.html > [2] https://mails.dpdk.org/archives/dev/2023-February/260668.html > > >> Other > >> than that, your current patch might be OK, but, again, > >> I think other reviewers' comments (if any) shall > >> be addressed. But no strong objections from me. > >> > >> By the way, for this "specialise" field, in your opinion, > >> which extra flags could emerge in future / would be nice > >> to have? I mean, is there any concept of what can be > >> added to this field's namespace and what can't be? > > > > I think there is no limit with hint flags to be added. > > I repeat it again: hints can be ignored by the PMDs. > > Thank you. The template flow API is experimental and will probably remain as such for a long time, so if you find a more elegant approach, we will consider it. But given we don't know how to make it better today, and there is no real problem with its definition, I don't see a reason to postpone its integration as experimental. In my opinion, having hint is good. The real discussion is on the flags. If we find how to manage the same optimization without these flags, we could drop them, but the hint flexibility should remain.