Interesting. Initially I had no ingress policy set up and after a huge amount of traffic I set it to 1024 (along with the burst at 80%) and observed a delay. Then I started my experiment adding a broad policy (4096 and 80% burst) before triggering the syn flood. This time when the new incoming policy (1024) was added, I experienced no delay at all. Anyway, hope this helps anyone in the future.
Ben, thanks for your help! 2016-09-11 19:04 GMT-03:00 Ben Pfaff <b...@ovn.org>: > OVS just configures the kernel QoS implementation. If there's a delay, > it comes from the kernel and OVS has no influence over it. > > On Sun, Sep 11, 2016 at 03:16:25PM -0300, Frederico wrote: >> No luck. I have tried different burst amounts. Ranging from 0 to 1024 >> and in every attempt it still takes some 5 to 10 seconds until I see >> any effect. Also, the documentation doesn't say anything about any >> delay regarding ingress policies. >> >> 2016-09-11 1:01 GMT-03:00 Ben Pfaff <b...@ovn.org>: >> > On Sat, Sep 10, 2016 at 03:14:37PM -0300, Frederico wrote: >> >> I am successfully applying the following speed limiting rules: >> >> >> >> ovs-vsctl set interface s0-eth1 ingress_policing_rate=1024 >> >> ovs-vsctl set interface s0-eth1 ingress_policing_burst=0 >> >> >> >> However, it takes some seconds (between 5 and 10, usually) until I see >> >> any practical effect on s0-eth1. Are those rules supposed to take all >> >> this time to kick in? >> > >> > I think your burst size is poorly chosen. Try 80% of 1024, or about >> > 800. See the documentation for more information. >> >> >> >> -- >> Thanks, >> Frederico Schardong -- Thanks, Frederico Schardong _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
