Re: [RFC] ethdev: add template table insertion and matching types

[Thomas Monjalon <thomas@monjalon.net>]

23/01/2023 23:02, Alexander Kozyrev:
> > 21/01/2023 00:06, Alexander Kozyrev:
> > > > 14/12/2022 03:21, Alexander Kozyrev:
> > > > > Bring more flexibility and control over both flow rule insertion
> > > > > and packet matching mechanisms. Introduce 2 new flow table types:
> > > > >
> > > > > 1. Allow a user to specify the insertion type used in template tables.
> > > > > The insertion type is responsible for choosing the appropriate key
> > > > > value used to map inserted flow rules into a template table.
> > > > >
> > > > > Flow rules can be inserted by calculating the hash value for
> > > > > the pattern or inserted by index via the new create_by_index() API.
> > > > > The idea of the index-based insertion is to avoid additional matches
> > > > > and simply execute predefined actions after jumping to the index.
> > > >
> > > > I don't understand the idea.
> > > > Why is it avoiding additional matches?
> > >
> > > If you jump directly to an index in a table, you don't need to match
> > anything.
> > > For the regular pattern-based table you must calculate the hash and match
> > on it.
> > 
> > I don't get it. I think it would be simpler with an example.
> 
> This is how the regular pattern-based table works:
> you calculate hash on 5-tuple, go to the table entry with the corresponding hash,
> check if there is a collision and search for the proper entry if so, execute actions.
> Index-based table:
> take an index value from a specified field, go to this index, and execute actions.

OK, please make sure the explanation is clear in the patch.


> > > > > The insertion to an already existing index is undefined and
> > > >
> > > > Why is it undefined?
> > >
> > > The behavior is up to a PMD to decide. It is free to replace the rule or throw
> > an error.
> > 
> > An undefined behavior of an API makes applications not portable.
> > Why not deciding of a behavior? You are not sure what is best?
> 
> We don't want to restrict a PMD behavior here. 
> Personally, I would prefer throwing an error in this case.
> Do you think returning EEXIST is better?

I don't know what is best.
At least you can define an error EEXIST if the PMD forbids it,
and no error if the PMD replaces the rule.