Hi Ivan, > -----Original Message----- > From: Ivan Malov <ivan.ma...@arknetworks.am> > Sent: Wednesday, 1 February 2023 16:04 > > On Wed, 1 Feb 2023, Thomas Monjalon wrote: > > > 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. > > I hear ya. > > > > >> 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. > > Yes, but something similar can be devised to attach > some "always the same exact spec" meaning to given > items in the pattern. Not necessarily via this bit. > We thought about it but it made the api to complex but we can revisit it. I'm open to suggestions.
> > > >> 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. > > Agreed. > +1 > > > >> 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. > > I'm questioning this because I suspect that, had the original > flow design had more flexibility / better decomposition, > then perhaps it would have been unneeded to add these > extra hints in the first instance. I don't mean to > criticise them too much, though. > One of the problems is that the API is too flexible this means that PMD must assume everything so it can't optimize, this is why we need hints . > > > >> [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. > > Thanks for explaining this. > > You know, now you mention it, are there non-debug app > examples available that make use of this template API? > Back in the day, I reviewed the template API, but > since then, I've never come across any real-life > examples. I'd appreciate you point something out. > > > 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. > > > > > > > > Thank you.
