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

Iben Rodriguez iben.rodriguez at gmail.com
Sat May 5 17:58:18 UTC 2012


Justin - can the idle time be easily adjusted?  Kind of like a TTL?

I b e n

On Sat, May 5, 2012 at 10:24 AM, Justin Pettit <jpettit at nicira.com> wrote:
> If the packets were spaced out enough, the kernel flows may have been
> already evicted. Idle kernel flows will only stay in the kernel ~5 seconds.
> If you run something like a ping that sends a packet every second, it should
> stay in the kernel.
>
> --Justin
>
>
> On May 5, 2012, at 2:21 AM, "Danny Y. Huang" <yuh024 at cs.ucsd.edu> 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?
>
> Thank you.
>
> Danny Y. Huang
> Ph.D. Candidate
> Systems and Networking Group
> University of California, San Diego
> http://sysnet.ucsd.edu/~dhuang/
>
> _______________________________________________
>
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>



More information about the discuss mailing list