> 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. > > 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. > > depends on PMD implementation. An old rule must be destroyed first. > > The index cannot be bigger than the size of the table. > > > > 2. Allow a user to specify the hash calculation function used in template > > tables. The hash calculation type is responsible for the calculation of > > the flow rule index a packet would hit upon arrival at the table. > > > > Control over this is useful for applications with custom RSS algorithms, > > for example. An application can select various packet fields to serve as > > a hash calculation source and jump to the appropriate flow rule location. > > The RSS hash result will be used as the index in the table. For the linear > > hash function, the mapping is one-to-one and the hash result is the index. > > For other hash functions, the index is the hash result module table size. > > The RSS hash result can be retrieved via modify_field API: HASH_RESULT. > > > > Signed-off-by: Alexander Kozyrev <akozy...@nvidia.com> > > --- > > doc/guides/prog_guide/rte_flow.rst | 20 +++++++ > > lib/ethdev/rte_flow.c | 24 ++++++++ > > lib/ethdev/rte_flow.h | 96 ++++++++++++++++++++++++++++++ > > lib/ethdev/rte_flow_driver.h | 11 ++++ > > lib/ethdev/version.map | 3 + > > 5 files changed, 154 insertions(+) > > Is there a PMD implementation available on the mailing list? > This is required to accept a new API. This is RFC. PMD implementation will follow in a v1 patches shortly.
