Hey Mike,
Thanks for the concern, please see my reply below: I guess you only care about ovs master right? On Fri, Jun 20, 2014 at 8:03 AM, Polehn, Mike A <mike.a.pol...@intel.com> wrote: > The idle timeout of 1.5 seconds for exact match flows creates big problems > for testing. I suspect that other than for internal generated flows within > the system, that 1.5 seconds is not a reasonable timeout. I worry about > thrashing of the flows in a congested setting where the load is so high > that packets are discarded from not having enough time to setup flows and > the discarded packets cause flows to be deleted since the packets that > would maintain the flows are not seen. This type of an issue combined with > other similar type issues can greatly reduce the overall network > performance. One way to approach this is to get the network performance > working well and then retune such parameters that could have an impact. > > Imagine someone using ssh terminal, there would be new flows constantly > being created and destroyed for each small user hesitation. Imagine that a > lot the communications through to the system happen to be through ssh > terminals and the system was gateway for these communications to a lot of > systems. The network performance for this case would probably degrade down > to the flow setup performance. This is just one example of many that could > exist, while there are of course scenarios that 1.5 seconds would be ideal. > I think the setting of 1.5 seconds is due to inexperience and needs to be > drastically changed. If flow timeout is specified on the OpenFlow command, > the exact match flow timeout should use the OpenFlow set timeout and not an > arbitrary value since there was probably a reason for setting the > particular value. > > I think your analysis makes sense. To my understanding, we currently do not consider the external issue (i.e. congested network causing pkt loss). The '1.5 seconds' is for keeping the set of megaflows in kernel datapath small, to guarantee lookup performance. One thing about using OpenFlow timeout, to me, it sounds like a big responsibility added to controllers (to monitor and maintain the OpenFlow flows). Also, if lookup pipeline is built via the 'resubmit' action, multiple OpenFlow flows will be hit and it is hard to generalize the idle timeout of the final datapath flow. I'll discuss within the team and reply back later. Maybe we should find a better default as you suggested. > Currently I use a patch for testing that sets the idle timeout to 15 > seconds and it solves a big issue of the OVS not being able to setup flows > fast enough for high speed flows, since my equipment (which is industry > standard network test equipment that I cannot modify) can be set to send > small set of packets at a low packet rate before sending the high speed > flows, but there is a moderate time gap of 11 seconds between these two. > > Then, you definitely should use this command for now, Example, ovs-vsctl set Open_Vswitch . other_config:max-idle=100000 /* sets the dp flow idle time to 100 seconds. */ > It is not obvious to me how to set the OVS idle from an exterior > interface. Can an example, or documentation update to indicate exactly how > to set this new idle timeout parameter. Hopefully this is a global setting > and not flow specific setting. > > This is a global setting on branch-2.0 - Master. We add this command only for testing and mis-using it could cause aged flows in kernel. So, it is not documented. > > > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Alex Wang > Sent: Thursday, June 19, 2014 9:20 PM > To: dev@openvswitch.org > Subject: [ovs-dev] [Backport] Backport max-idle to branch-1.10 - > branch-2.1. > > This series backports the commit 72310b04 (upcall: Configure datapath > max-idle through ovs-vsctl.) to branch-1.10 - branch-2.1, for testing > purpose. > > -- > 1.7.9.5 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
