I've known about this problem for years now, but I've always ignored it because it didn't seem to cause trouble in practice.
I have a favorite straw-man approach. It won't work as-is, but perhaps it will spur someone to an idea that would work. Suppose that we changed the semantics of the kernel "flow_put" so that, when the kernel puts the flow, it locks the socket buffer of the Netlink socket used to send packets in that flow to userspace, scans it for other packets in the flow, removes them from the socket buffer, and executes their actions. Problems with this idea include, at least: 1. Nothing does anything like this with socket buffers (that is, there is no precedent for deleting packets queued to userspace from a socket buffer) and it seems wrong. 2. Identifying the socket buffer or buffers to scan is problematic (maybe the client would have to identify them). 3. The flow_put would have to arrange for any other packets arriving after it locks the socket buffer to block until it finishes processing the buffered packets, so that those arriving packets would be processed through the new flow in the normal way, but guaranteed to be ordered after the ones in the socket buffer. (This probably isn't hard.) _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss