Although packet reordering will happen due to upcall handling, there is one corner case we could fix, namely the following:

When using per-CPU upcall handling, the packet is sent to the CPU's specific queue, which is handled by a userspace revalidator thread. However, this thread is free-running and not bound to the same CPU it is servicing. This is not a problem if the packet is sent to its final destination, as all the execute commands in the kernel come from the same thread and are sent out in order. However, when there is a recirculation action, the packet needs another upcall, and now it comes from the handler thread's CPU, so it might be processed by a different handler. So now, when the second flow is added, some packets already queued to the second handler might arrive out of order compared to packets already queued on the first handler.

We should find a way to make sure this does not happen. Maybe we could pass an attribute with the execute request indicating the incoming CPU (handler), so that subsequent upcalls are sent to the same handler.