17/02/2021 11:37, Ferruh Yigit:
> On 2/17/2021 5:57 AM, Asaf Penso wrote:
> > From: Ferruh Yigit <ferruh.yi...@intel.com>
> >> On 2/7/2021 10:52 AM, Asaf Penso wrote:
> >>> In http://doc.dpdk.org/guides/nics/overview.html, table 1.1 lists all
> >>> supported features.
> >>> It has a single line for "Flow API" that refers to rte_flow support.
> >>> rte_flow is composed of many items and actions that are not expressed
> >>> in this single line.
> >>>
> >>> The following new tables are suggested:
> >>> 1. rte_flow items
> >>> 2. rte_flow actions
> >>>
> >>
> >> Hi Asaf,
> >>
> >> I understand the intention, but I am not sure about this.
> >>
> >> The Flow API does not provide a capability or feature list in the API
> >> level, by
> >> design, because it is very hard to do it correct, but this patch tries to
> >> do it in the
> >> documentation level.
> >>
> >> This will be missing lots of details, the flow items and actions
> >> documented as
> >> supported may and may not be supported based on the details.
> >>
> >
> > Which missing details are you referring to? All flow items and all actions
> > are listed.
> >
>
> Patterns are complex, any rule can be valid or invalid based on provided
> pattern
> values (details), also any rule can be valid or invalid based on previous
> rules
> or configuration.
>
> In practice this information is much more useful if it is provided by API,
> but
> we are not able to do it because of its complex nature, it should be same
> level
> of complexity to provide this information by documentation.
>
> >> It will be very hard to read this table (when it becomes full), also will
> >> be very hard
> >> to maintain.
> >
> > As part of any documentation change in rte_flow the developer would also
> > need to update this table.
> > Why would it be very hard to maintain?
> >
>
> Ahh, that sound so simple when you say like this :) In practice even keeping
> feature list requiring lots of effort, developers are
> missing/neglecting/ignoring updating documentation when updating the code.
>
> And for this case is partially correct table a useful information? If this is
> not completely correct people won't rely on it and it will become just
> useless.
> So this feature should come with an automated way to detect if a rule
> supported
> but not documented, or even better this table should be generated from code
> automatically.
>
> >>
> >>
> >> Let me start with a question, who do you think will be your consumer?
> >> Who will benefit from this table and how?
> >
> > We get a lot of questions from users regarding rte_flow support and we do
> > not have a single place with proper documentation.
> > I can ask the same about the overall feature table, right? There is a value
> > to document the support.
> >
>
> Let's discuss the feature table separately, I think that is a valid question.
>
> For the rte_flow, who is asking questions? End user, or application
> developer?
> So is this intended to be a marketing documentation or technical
> documentation?
>
> And what is the nature of the questions, if it is related to the rte_flow,
> there
> is already a proper documentation for it:
> https://doc.dpdk.org/guides/prog_guide/rte_flow.html
>
> If this question is if any specific rule supported by a specific PMD, right
> now
> only valid way to say this that I am aware of is, run 'rte_flow_validate()'
> and see.
> Not sure if we can document this properly.
I think in general we are missing a big disclaimer
on top of this overview page:
Each feature may have some hardware limitations.
Then there is a need, both for application developers and end-users,
to know which feature can be supported by a PMD,
or which PMD can support a feature.
Yes there are complex limitations with hardware offloads in general.
Yes it would be nice to report some tested capabilities with a CI.
But it does not mean we should not try to document it in my opinion.
