Add API for packet vectorized / async processing

[RaoulDotSh]

Our goal is to use alternative ciphers for performance improvements, and the next step will be to support Async jobs with openssl 3.0.0.

We are making progress on the quicly integration in VPP (https://github.com/FDio/vpp/tree/master/src/plugins/quic), it works as it but we began to modify the code in order to optimize performances by batching cipher operations

For now we are able to use our own cipher engine by modifying quicly and picotls code (replacing ptls_aead_encrypt() / decrypt() and ptls_cipher_encrypt() / decrypt() functions ptr).

Currently we are trying to modify quicly to push a cipher operation for each packet and then process all operations just before sending/receiving data. This behaviour needs many modifications in quicly and we want to discuss about that. We plan to invest time on this evolution and make a PR, but if you have some ideas or suggestions about that we’re open.

[kazuho]

Thank you for using quicly in VPP.

I have always had adding support for crypto offload as one of the possibilities. Let's make that happen. FWIW, what I have had in my mind is something like this:

• Create your own ptls_cipher_suite_t, that declares itself as doing AES128GCM (or the cipher you offload), but in fact is a no-op. [a]
  • This cipher suite will be registered to ptls_context_t that is referred from quicly_context_t.
• Create a callback interface (like quicly_packet_allocator_t, quicly_cid_encryptor_t, ...) that does the packet encryption and decryption (calling it quicly_codec_t for now; I do not have a strong opinion about the name). [q]
  • Current code (i.e. software codec) would be called like quicly_default_codec_t, and the implementation would be moved to lib/defaults.c.
  • You might want to look into how quicly_cid_encryptor_t and st_quicly_default_encrypt_cid_t are defined and used. It resembles the design pattern I am talking here.
• Add a void pointer to quicly_datagram_t that can be used to carry arbitrary data [q]
  • This would be used to pass values from your no-op cipher to the crypto offload engine.
• Depending on the need, also add flag(s) to quicly_decoded_packet_t for the decode side. [q]

The bullet points marked [q] are the changes that would happen in quicly. Those marked [a] are the things that would happen on the application (e.g., VPP) side.

All that said, I am open to discussing any other approaches. Please let me know what you think.

[RaoulDotSh]

Thanks a lot for your response.

The first point is ok for us (create our own ptls_cipher_suite_t and register it in ptls_context_t/quicly_context_t), this was already done in vpp quic plugin and works well with our internal crypto engines.

For the other things we need to try this and see if your design can works with our needs. We will come back to you soon to discuss about that.