Hi All,
To avoid multi threads, I will only answer this thread since I assume
everyone is clear about the issue.
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
>
> On 9/21/22 12:40, Thomas Monjalon wrote:
> > 21/09/2022 11:04, Ivan Malov:
> >> Now it's clear to me that your intention is to match on exact ports,
> >> as usual, but this time with a hint for the flow table. Got it.
> >>
> >> In your response, you say that matching on ALL vports is not what
> >> the use case needs. OK, I understood. But please note that the
> >> item name does not say "ALL", it says "ANY".
> >>
> >> OK. Say, "ANY" is also confusing. Let's then name it "VPORTS_ONLY"
> >> and "PHY_PORTS_ONLY". This way, if user provides item VPORTS_ONLY
> >> and then provides item REPRESENTED_PORT, these two items do not
> >> contradict each other. Item VPORTS_ONLY defines the scope of some
> >> kind, then the following item, REPRESENTED_PORT, makes it narrower.
> >>
> >> And, in documentation, one can say clearly that the user *may*
> >> omit item VPORTS_ONLY in the exact rule pattern provided that
> >> they have already submitted this item as part of the template.
> >
> > I think the problem that Rongwei & Ori are trying to solve
> > is to allocate resources for the templates table in the right place.
> > A table can have multiple templates.
> > If all rules/templates for this table are dedicated to virtual ports,
> > then the table will be allocated in a place managing only virtual ports.
> > This allocation decision must be taken at table creation,
> > whereas rules will be created later.
> > In order to do this specific table allocation for vports,
> > we need to restrict all templates of the table to be "vports only".
> >
> > I hope it makes things clearer.
> > Now the question is how to achieve this? Solutions are:
> >
> > 1/ give a hint to the table allocation
> > 2/ insert a pattern item in all templates of the table
> >
> > I don't see any other solution. Please propose if there are more options.
> >
> >
>
> See my mail
>
> 3/ use jump rule which ensures that all traffic meets out
> expectations
>
> It means that the table creation could be postponed. Or the
> table could be per-configured at the point of creation and
> finalized when we know that all traffic will be from wires
> or from vports. Yes, it complicates internals to achieve
> the optimization.
Sorry Andrew your suggestion is not a valid one for the following reasons:
1. table creation can't be postponed this is a key idea of the rte_flow
template API.
2. we can never know what rules will be inserted if the application doesn't
tell us.
how can we know this is the last rule? What do we do with the first rule?
3. I don't see how jumping helps since it worsens the issue when you jump to a
table,
how does the PMD know if this table should have only wire or only vports?
I agree with Thomas, there are two valid options, I vote for the hint since
this is the
feature idea to tell the PMD where this resource should be allocated.
Best,
Ori
