[ovs-discuss] Kernel-space and user-space flow tables

[Ben Pfaff]

On Sat, May 05, 2012 at 05:21:50PM +0800, Danny Y. Huang wrote:
> Hello, I am a graduate student. I've been trying to understand why OVS
> keeps one flow table in kernel, and the other in the user-space. In
> particular, why would the flow still have to go through the user-space,
> even though the relevant rules haven already been set up in the kernel's
> flow table?
> 
> To illustrate this problem, I ran a simple experiment that involves two
> hosts as traffic source and sink, a host that ran OVS, and a host that ran
> NOX. The controller application would install a rule for any new flows.
> 
> First, I started OVS with an empty flow table. Then I had a packet sent
> from the source host to the sink. Since this was a new flow,
> ovs_flow_tbl_lookup() would not find the flow's key. As a result, the
> kernel module sent the flow to the user-space via ovs_dp_upcall(). Once
> inside the user-space, the insert_rule() within classifier.c was invoked,
> followed by the installation of the rule in the user-space flow table, and
> subsequently in the kernel's flow table.
> 
> Here's where the confusion kicks in. I had the same packet sent from the
> source host to the sink the second time. I expected that, since the
> kernel's flow table already contained the relevant rule, the flow would be
> matched entirely within the kernel, and that no user-space would be
> involved. However, I was wrong. As the packet arrived,
> ovs_flow_tbl_lookup() still reported that the flow-key was not found,
> causing ovs_dp_upcall() to be invoked. While in the user-space, a
> classifier_lookup() was carried out and the flow was found in the flow
> table. The rule was added to the kernel module's flow table again, via the
> ovs_flow_tbl_insert() call, as if the events in the previous paragraph had
> not happened at all.
> 
> I had the same packet sent through OVS the third time. Again, an upcall was
> made, the flow was found in the user-space's flow table, the rule was
> inserted in the kernel module's flow table, before the kernel module
> executed the rule's actions.
> 
> It seemed that a flow had to repeatedly go through the user space even
> though it has a matching rule. Why is this so? Why would the kernel
> module's flow table fail to remember installed rules, while the one in
> classifier.c managed to do so?

What rule does the controller insert?