Dpdk backend: Support for large keysize >64 bytes with additional restrictions

[usha1830]

Earlier, dpdk target had a limitation of keysize to be within 64 bytes including any holes in the key fields in the underlying structure.

Ex:
struct meta {
bit <8> meta1; // table key
bit <32> meta2; // hole
bit <64> meta3; // table key
}

table {
keys = {
meta3: exact;
meta1 : exact
}
}

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.

[mihaibudiu]

have enums been eliminated?

[usha1830]

Yes. Enum elimination is done in midend.

[usha1830]

@mbudiu-vmw Can this be merged?