The main goal of this series of patches is to reverse a regression in
netperf TCP_CRR performance results that was noticed in the transition
from Open vSwitch 1.2 to 1.3.  The Netperf documentation describes
TCP_CRR as:

        A TCP_CRR test is like a merger of a TCP_RR and TCP_CC test
        which measures the performance of establishing a connection,
        exchanging a single request/response transaction, and
        tearing-down that connection.  This is very much like what
        happens in an HTTP 1.0 or HTTP 1.1 connection when HTTP
        Keepalives are not used.  In fact, the TCP_CRR test was added
        to netperf to simulate just that.

Performance optimizations in the Open vSwitch 1.3 series focused on
cases in which many flows must be set up at a time (as measured by
ovs-benchmark).  However, the TCP_CRR test keeps only a single
connection in flight at any given time.  At any time, progress
requires getting a response to the packet sent most recently.  The
performance for TCP_CRR actually dropped:

                                TCP_CRR                 ovs-benchmark
                                --------------          -------------
branch-1.2                      1237/1047/1042           9063
branch-1.3                       765/ 785/ 811          13310

(I report the values for three consecutive runs of TCP_CRR, since that
tends to have a lot of variance, but only one for a 20-second run of
ovs-benchmark because that is much more stable.)

This series improves matters.  I originally developed it against
branch-1.3.  The following are the numbers I measured for each commit
when it was on branch-1.3.  (The baseline numbers differ from
branch-1.3 above because I ran them in slightly different environments.)

                                TCP_CRR                 ovs-benchmark
                                --------------          -------------
branch-1.3 baseline              885/ 840/ 854          12126
  + Remove poll_fd_woke()...     706/ 584/ 592          10832
  + Use poll() internally in...  884/ 851/ 818          12734
  + Use "epoll" instead of...   1083/ 999/ 998          12807
  + Process multiple batches... 1300/1295/1302          12440
  + Add "fast path".            1593/1580/1647          13716
------------------------------  --------------          -------------
improvement versus baseline       +87%                   +13%

I ran the same tests on current "master" versus with all the patches
applied, without breaking it down by individual patch, and saw similar
improvements:

                                TCP_CRR                 ovs-benchmark
                                --------------          -------------
master commit 0145d7ed02095      868/ 813/ 800          12153
  + this series of patches      1527/1556/1553          13675
------------------------------  --------------          -------------
improvement versus master 0145    +87%                   +13%
improvement versus branch-1.2     +39%                   +51%

Ben Pfaff (6):
  dpif-linux: Remove poll_fd_woke() optimization from
    dpif_linux_recv().
  Revert "poll-loop: Enable checking whether a FD caused a wakeup."
  dpif-linux: Use poll() internally in dpif_linux_recv().
  dpif-linux: Use "epoll" instead of poll().
  ofproto-dpif: Process multiple batches of upcalls in a single poll
    loop.
  ofproto: Add "fast path".

 lib/dpif-linux.c           |  109 +++++++++++++++++++++++++++++--------------
 lib/netlink-socket.c       |   15 ++++--
 lib/netlink-socket.h       |    2 +-
 lib/poll-loop.c            |   33 ++-----------
 lib/poll-loop.h            |    3 -
 ofproto/ofproto-dpif.c     |  113 +++++++++++++++++++++++++++----------------
 ofproto/ofproto-provider.h |    1 +
 ofproto/ofproto.c          |    6 ++
 ofproto/ofproto.h          |    1 +
 vswitchd/bridge.c          |   10 ++++
 vswitchd/bridge.h          |    3 +-
 vswitchd/ovs-vswitchd.c    |    2 +
 12 files changed, 182 insertions(+), 116 deletions(-)

-- 
1.7.4.4

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to