[ovs-dev] User-space and kernel-space flow tables

Danny Y. Huang yuh024 at cs.ucsd.edu
Sat May 5 09:22:20 UTC 2012


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?

Thank you.

Danny Y. Huang
Ph.D. Candidate
Systems and Networking Group
University of California, San Diego
http://sysnet.ucsd.edu/~dhuang/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20120505/3f6124b9/attachment-0003.html>


More information about the dev mailing list