On Fri, Apr 05, 2019 at 07:21:50PM +0000, Deval, Manasi wrote: > I have a few small questions about OvS and how it has evolved since > the NSDI paper > (http://www.openvswitch.org/support/papers/nsdi2015.pdf)
> The paper discusses how the reactive method of flow addition was not > scalable, hence the cache was populated with mega-flows. The mega-flow > is made up of multiple tables where the match schema for each table > differs. A flow may only be found in a single mega-flow table. There > is a section that talks about the initiation of the mega-flow match > through a micro-flow match. A direct mega flow lookup was expensive so > the mega-flow is put in cache after microflow lookup because this > scheme was more performant. Direct mega-flow lookup needed multiple > hashes that simultaneously match all the different hash tables. The > question I have here is - if the cost of directly matching a mega-flow > were low, would there be a reason to even take the alternate path? > What is the typical number of hashes typically in use? Some of your terminology is wrong. The term "megaflow" only refers to the cache in the datapath, which only has one table anyhow. There are multiple OpenFlow tables that contain flows, which aren't called megaflows or microflows, just "OpenFlow flows" if clarification is needed. I don't know what alternate path you mean. The number of hashes varies widely depending on the OpenFlow tables and the traffic pattern. > Secondly, my understanding from the paper is that the mega-flow and > microflow have the exact same actions in terms of tunnel and NAT > management. This gets a little confusing in the context of connection > tracking. Since the connections are being tracked on a micro-flow > basis, do folks see that micro and mega-flows will exist in different > tables simultaneously, where mega-flow rules have tunneling actions > and micro-flow rules have connection tracking? I guess when you say "microflow" here, you mean connection tracking entries. There can be many connection tracking entries for a single megaflow, corresponding to all the connections handled by the megaflow. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
