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 0CC1841B9E; Wed, 1 Feb 2023 12:50:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A317442BC9; Wed, 1 Feb 2023 12:50:44 +0100 (CET) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id D584C406A2 for ; Wed, 1 Feb 2023 12:50:42 +0100 (CET) Received: from debian (unknown [78.109.71.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id BF304E0162; Wed, 1 Feb 2023 15:50:41 +0400 (+04) Date: Wed, 1 Feb 2023 15:50:53 +0400 (+04) From: Ivan Malov To: Thomas Monjalon 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 In-Reply-To: <1707507.QkHrqEjB74@thomas> Message-ID: References: <20221114115946.1074787-1-rongweil@nvidia.com> <1707507.QkHrqEjB74@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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 Hi Thomas, On Wed, 1 Feb 2023, Thomas Monjalon wrote: > 31/01/2023 06:30, Ivan Malov: >> Hi Rongwei, >> >> OK, I hear ya. Thanks for persevering. >> >> 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. 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. 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? 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? [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.