Polling Mode vs. Interrupt Mode¶

There are two methods by which TNSR can acquire new data to process for cryptographic operations and for packets on interfaces: Polling mode and Interrupt mode. There is also an adaptive option that blends the behavior of these two methods. TNSR uses polling mode by default.

Polling Mode:

In polling mode, the CPU is kept in a tight loop constantly checking for new data to process.

This way the system is processing data as fast as it can be obtained, but at the cost of potentially consuming more power, generating more heat, and showing CPU cores involved in these operations as consuming 100% CPU at all times.

Interrupt Mode:

Interrupt mode allows the hardware to signal that it has new data to process, at which time TNSR will process the new data in batches.

In some cases this can be slower at noticing new data than polling mode. However, VPP is very efficient at processing batches of data, so it can potentially be faster for certain workloads. There is a possibility of increased latency and reduced throughput, but it depends on the hardware, environment, and workload. Since interrupt mode is not constantly running CPU cores at 100% like polling mode, it can consume less power and generate less heat.

Warning

The interface drivers must fully support interrupt mode or it will not function properly. For example, packets may arrive but the driver may not generate interrupts, so the dataplane does not receive the packets.

If packets fail to pass on an interface after changing it to interrupt mode, then that interface is not capable of using interrupt mode with the current driver.

This is known to be an issue with the following interfaces:

Azure

This limitation may affect other types of interfaces as well.

Interrupt mode is known to work on bare metal hardware (except as noted in the previous warning), as well as in AWS and KVM environments.

Adaptive Mode:

Adaptive mode is intended to improve throughput and reduce latency over plain interrupt mode by polling when an interface is busy receiving packets and waiting for an interrupt when it is not busy.

When an interface is set to use adaptive mode, a flag is set on the interface to indicate that it is in adaptive mode, but the device is actually put into interrupt mode. Later, the dataplane can check the activity level of the input node on the interface. If the adaptive flag is set and the amount of incoming packets crosses a certain threshold, the device can automatically be switched to polling mode. When the adaptive flag is set and an interface has been switched to polling mode, if the amount of incoming packets drops below a certain threshold, the device can automatically be switched back to interrupt mode.

As this makes use of interrupt mode, it has the same device driver limitations as interrupt mode.

Switching completely to interrupt mode requires setting asynchronous cryptographic processing and all supported interfaces to interrupt mode.

Asynchronous Cryptographic Processing¶

With asynchronous cryptographic processing, encrypted and decrypted packets are processed by polling for completed operations by default. This behavior can optionally be interrupt-based.

The following command configures the asynchronous cryptographic processing mode:

tnsr(config)# crypto asynchronous dispatch-mode (adaptive|interrupt|polling)

Interfaces¶

Interfaces can individually be set to use interrupt or polling mode to acquire new packet data. The rx-mode command in the Interface Configuration Options controls this behavior. Polling mode is the current default behavior.

tnsr(config)# interface <name>
tnsr(config-interface)# rx-mode (adaptive|interrupt|polling)

This option can be set on hardware interfaces and virtual interfaces (e.g. VPN and other tunnels), but it cannot be set on VLAN subinterfaces.

Note

As mentioned previously, to fully transition to interrupt mode, every supported interface must be set to interrupt mode along with asynchronous cryptographic processing.