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. > > > 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?
