Improving the performance of aes-encrypter network function

[madhura-a]

Bug Report

Current Behavior When I run aes-encrypter network function, I can see a lot of packets getting dropped at the receive ring of the network function (rx_drop). rx_pps and tx_pps are almost equal. So I tried increasing the size of the rings of NFs, but no improvement. How can we improve performance?

Additional context/Screenshots

[twood02]

This NF is intended to be an example of a slow, CPU intensive function. The performance is probably limited by the AES algorithm (it may not be doing anything smart like using hardware acceleration).

In this case, adjusting the ring size or other batching parameters won't have much effect. If you need higher throughput you can always start more replicas of the NF and then the manager will distribute flows across them (if they have the same service ID).

[VenkataramiReddyCh]

Thank you for your response. We know that only one core can be allocated to each NF instance. As AES encryption is CPU intensive, to increase throughput, can we allocate more cores instead of creating more replicas? Does openNetVM supports pinning of more cores to a single NF instance?

[twood02]

Starting multiple replicas is the simplest way to achieve this. If you want to have multiple threads within a single NF process (mainly useful if you have shared state for your NF, which won't matter here), then you can use our scaling API to start more threads each executing the NF's main loop. You can look at https://github.com/sdnfv/openNetVM/tree/master/examples/scaling_example for an example of how this works. This will require some modifications to the NF, whereas starting multiple replicas would not require changes.

In either case, packets are distributed to NFs based on the RSS hash. This provides flow consistency (a flow always goes to the same core) unless you are dynamically adding and removing threads or instances over time. In that case you might have to make a stateful load balancer if you need to provide flow consistency.