Dpdk backend: Support for large keysize >64 bytes with additional restrictions #3580
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Earlier, dpdk target had a limitation of keysize to be within 64 bytes including any holes in the key fields in the underlying structure.
This limitation is now removed but newer restrictions are imposed and based on the conditions a copy of tables keys should be made to make them come from the same underlying structure and make them contiguous in the underlying structure.
The following conditions are checked to make decision about making a copy of the header/metadata field used as table key.
As before, all the table key fields must be part of the same structure (either header or meta-data).
As before, a mix of header and meta-data fields in the table key requires copying the header fields to meta-data.
“Regular” tables (exact match, wildcard match): In the target implementation, if all fields are contiguous and exact match, the exact match table type is used, otherwise the wildcard match table type is used. Even if all the fields are exact match, if they are not contiguous, the wildcard match table type will be used. So in the case of a mix of header and meta-data fields in the table key, which requires a copying the header fields to meta-data, it is important is there is a hole in between fields: if there is a hole, the exact match table type cannot be used, which result in performance penalty.
P4C needs to do the best to make all fields contiguou. Sometimes, when there is a large gap between (A) existing meta-data fields and the (B) new meta-data fields (generated by the compiler to mirror the header fields), we should also create metadata copies for the (A) fields, so that the (A) fields and the (B) fields now become contiguous in meta-data , so the exact match table type could be used. This should be done for the typical case of relatively small key sizes with a relatively small number of fields, where performance delta might be important (if the key is very large, performance will be typically not great anyway); Heuristic adopted: copy only if the number of (A) fields is less than 5.
Learner tables (add_on_miss tables) are a special type of exact match tables: The key fields must be contiguous in their structure. If not contiguous, need to create meta-data copies for all key fields (in order to make the key fields contiguous).
This PR removes the validation for keysize limit and adds the new restrictions and makes copy of fields used as key based on the conditions described above.