[ovs-discuss] Flow Table Overload

scolfield kscolfield at gmail.com
Thu Mar 3 22:47:16 UTC 2016


Hi, everyone,

I've been running some tests on OVS 2.3 under Mininet emulation framework.

I'm interested in overloading flow table and see how RTT can be affected as
the flow table size grows. In the literature, we can see some works doing
performance tests with OVS flow tables, similarly, like this one that I've
been doing.

My question may sound a little obvious, but "*how do we overload OVS flow
table?*", because the way I've been doing, it seems that the network
performance is not getting worse as I increase the number of flow entries
via ovs-ofctl command.

The flow entries that I'm using is defined by: Eth src, Eth dst, IP src and
IP dst. And I've run tests with 2000 entries and 8000 entries, but the RTT
(ping) that I achieve is the same. About 0.073 ms.

What I've been expecting, it was something like 0.073 ms and 0.084 ms. Not
necessarily these values, but a clear difference between them. So as I
increase flow table entries, it seems that no matter how many flow entries
are, the RTT would not change. Or at least, it would be always something
around 0.073, such as 0.072 and 0.074.

*Have I been missing something? or are the number of entries too small and
close to other? *

Another doubts that I have is related to the maximum flow table size. As I
could understand by reading docs related to OVS, the flow table has evolved
a lot since the beginning and the maximum flow table size it seems to be
200 000 entries on OVS 2.3. Here, is not clear to me. *Does this size refer
to the user-space or kernel-space flow table? Either way, if the both table
are implemented on software level (hash table) and memories are allocated
dynamically, so the flow table size would not have to be "not determined"?
or relative to the hardware capacity?*

Could someone help me?

Thanks in advance,
Scolfield.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160303/4d709503/attachment-0002.html>


More information about the discuss mailing list