No. What is the use case for adjusting it?
On Sat, May 05, 2012 at 10:58:18AM -0700, Iben Rodriguez wrote: > 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 <[email protected]> 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" <[email protected]> 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 > > [email protected] > > http://openvswitch.org/mailman/listinfo/discuss > > > > > > _______________________________________________ > > discuss mailing list > > [email protected] > > http://openvswitch.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
