Open loalan opened 1 year ago
We should separate out hidden/implicit side effects such as 'reparse' and associated state modification from crypto.encrypt/decrypt methods and generalize it so that it can be used for other accelerators as well. Consider the following -
action ipsec_esp_decrypt(...) {
....
<existing methods to setup the decryption parameters>
....
ipsec_acc.decrypt(enable_auth);
if (reparse_packet() == True) {
results = ipsec_acc.get_results()
.... <check results, post_decrypt_actions >....
} else {
recirc_packet();
exit();
}
}
I see the following advantages of this -
Overall I think it will keep accelerator functions clean and code slightly more portable across targets.
IMHO: This is indeed good example for what we may expect to see with inline accelerators; but there are other (than IPSec) inline accelerations that will need to be expressed as well. The value of inline acceleration in this domain is clear. Also, most not-trivial accelerators will likely change a multitude of things. My hope is that the solution we land of is general enough to be reused in other inline accelerators that will be needed in the near future by all vendors.
https://p4.org/p4-spec/docs/P4-16-working-spec.html#sec-packet-data-extraction
The packet_in extern is special: it cannot be instantiated by the user explicitly. Instead, the architecture supplies a separate instance for each packet_in argument to a parser instantiation.
This example expands on the definition of crypto_accelerator (https://github.com/p4lang/pna/pull/53).
The example adds two methods for encrypt/decrypt that assumes that inline accelerators operate immediately on the packet (e.g. deparse, decrypt and reparse). Packet recirculation is not necessary for either inline method.
The example shows the use of inline encrypt and decrypt, as well as how the crypto accelerator results can be used.