On 6/28/25 12:01 AM, Ilya Maximets wrote: > When a packet enters OVS datapath and there is no flow to handle it, > packet goes to userspace through a MISS upcall. With per-CPU upcall > dispatch mechanism, we're using the current CPU id to select the > Netlink PID on which to send this packet. This allows us to send > packets from the same traffic flow through the same handler. > > The handler will process the packet, install required flow into the > kernel and re-inject the original packet via OVS_PACKET_CMD_EXECUTE. > > While handling OVS_PACKET_CMD_EXECUTE, however, we may hit a > recirculation action that will pass the (likely modified) packet > through the flow lookup again. And if the flow is not found, the > packet will be sent to userspace again through another MISS upcall. > > However, the handler thread in userspace is likely running on a > different CPU core, and the OVS_PACKET_CMD_EXECUTE request is handled > in the syscall context of that thread. So, when the time comes to > send the packet through another upcall, the per-CPU dispatch will > choose a different Netlink PID, and this packet will end up processed > by a different handler thread on a different CPU. > > The process continues as long as there are new recirculations, each > time the packet goes to a different handler thread before it is sent > out of the OVS datapath to the destination port. In real setups the > number of recirculations can go up to 4 or 5, sometimes more. > > There is always a chance to re-order packets while processing upcalls, > because userspace will first install the flow and then re-inject the > original packet. So, there is a race window when the flow is already > installed and the second packet can match it and be forwarded to the > destination before the first packet is re-injected. But the fact that > packets are going through multiple upcalls handled by different > userspace threads makes the reordering noticeably more likely, because > we not only have a race between the kernel and a userspace handler > (which is hard to avoid), but also between multiple userspace handlers. > > For example, let's assume that 10 packets got enqueued through a MISS > upcall for handler-1, it will start processing them, will install the > flow into the kernel and start re-injecting packets back, from where > they will go through another MISS to handler-2. Handler-2 will install > the flow into the kernel and start re-injecting the packets, while > handler-1 continues to re-inject the last of the 10 packets, they will > hit the flow installed by handler-2 and be forwarded without going to > the handler-2, while handler-2 still re-injects the first of these 10 > packets. Given multiple recirculations and misses, these 10 packets > may end up completely mixed up on the output from the datapath. > > Let's allow userspace to specify on which Netlink PID the packets > should be upcalled while processing OVS_PACKET_CMD_EXECUTE. > This makes it possible to ensure that all the packets are processed > by the same handler thread in the userspace even with them being > upcalled multiple times in the process. Packets will remain in order > since they will be enqueued to the same socket and re-injected in the > same order. This doesn't eliminate re-ordering as stated above, since > we still have a race between kernel and the userspace thread, but it > allows to eliminate races between multiple userspace threads. > > Userspace knows the PID of the socket on which the original upcall is > received, so there is no need to send it up from the kernel. > > Solution requires storing the value somewhere for the duration of the > packet processing. There are two potential places for this: our skb > extension or the per-CPU storage. It's not clear which is better, > so just following currently used scheme of storing this kind of things > along the skb. > > Signed-off-by: Ilya Maximets <[email protected]> > ---
The userspace counterpart that makes use of this fucntionality is available here: https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
