You say, "I am trying to associate each rule in the kernel's flow table with additional metadata." OK, great, we're finally getting to learn about your actual goal. So, tell us, what extra metadata do you want?
On Sun, May 06, 2012 at 09:23:38AM +0800, Danny Y. Huang wrote: > @Ben: Based on the output of "ovs-ofctl dump-tables br0", The rule > installed was "cookie=0x0, duration=71.813s, table=0, n_packets=1, > n_bytes=1500, > udp,in_port=1,vlan_tci=0x0000,dl_src=00:0c:29:b5:01:5e,dl_dst=00:0c:29:40:31:f5,nw_src=192.168.224.150,nw_dst=192.168.1.1,tp_src=10000,tp_dst=9 > actions=output:2". > > @Justin: You're right. Thanks! > > @Iben: I haven't had any luck locating the code that resets the kernel's > flow table every 5 seconds. Where can I find it? A TTL would be useful, I > agree. For my purpose, I am trying to associate each rule in the kernel's > flow table with additional metadata. It would be convenient if the kernel's > flow table can be more persistent. > > Thank you, all! > > - Danny > > On Sunday, May 6, 2012, Ben Pfaff wrote: > > > 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
