> On Jul 25, 2016, at 9:52 AM, Chiappero, Marco <marco.chiapp...@intel.com>
> wrote:
>
> Hello everyone,
>
> I’m currently carrying out RFC2544 based tests on a server running hundreds
> of applications which forward back a matching number of traffic flows
> generated by a HW traffic generator. These applications are running in Linux
> containers, bridged altogether by a single OvS bridge instance (using the DP
> kernel module).
>
> However a significant packet loss happens at the very beginning of every run
> beyond a certain line rate, somehow invalidating the tests. When slowly
> increasing the load by hand, from a minimum to the target rate, no such loss
> can be seen. Suspecting an initial delay due to the need to fill the
> microflow cache, I tried increasing the number of handler threads and their
> priority without success.
>
> Is this the expected behavior or could it be related to misconfiguration?
> What are the best practices for testing OvS, are there any better approaches?
Yes, this is known/expected behavior. Those tests were designed for hardware
switches, which don't generally have caches on their fastpath that need to be
heated up. I think this has been previously discussed on the mailing lists, so
you could search there. You may want to check out this presentation from the
2015 OVS conference:
https://www.youtube.com/watch?v=ZILwdFLy6c4
Here are the accompanying slides:
http://openvswitch.org/support/ovscon2015/17/1050-abidi.pptx
As they suggest, you may try increasing the max-idle value to something closer
to 50000.
This seems to follow some of the tuning suggestions done by other folks at
Intel when testing the DPDK port:
https://download.01.org/packet-processing/ONPS1.5/Intel_ONP_Server_Release_1.5_Performance_Test_Report_Rev1.2.pdf
Let us know what you find out. It's probably worth adding a FAQ entry.
--Justin
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
