Hi Ben, I was trying to associate each flow with its arrival time, as well as properties relevant to the emulator we're developing. We're using OVS to build an emulator that behaves like a physical switch. Thus, various performance aspects of the physical switch are tagged to each flow.
- Danny On Tuesday, May 8, 2012, Ben Pfaff wrote: > 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 w> > > <http://openvswitch.org/mailman/listinfo/discuss> >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
