1. 28 Sep, 2016 1 commit
  2. 27 Sep, 2016 7 commits
    • Jarno Rajahalme's avatar
      ofp-actions: Always consider inconsistent CT actions as an error. · d86e03c5
      Jarno Rajahalme authored
      We can't downgrade to OF1.0 and expect inconsistent CT actions
      be silently discarded.  Instead, datapath flow install fails, so
      it is better to flag inconsistent CT actions as hard errors.
      Signed-off-by: default avatarJarno Rajahalme <jarno@ovn.org>
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
    • Jarno Rajahalme's avatar
      ofp-actions: Check that 'alg=ftp' matches on TCP. · c9f7de8c
      Jarno Rajahalme authored
      Datapath flow setup fails when setting the FTP helper on an
      unsupported IP protocol.  It is better to fail at the OpenFlow rule
      set-up time instead.
      Signed-off-by: default avatarJarno Rajahalme <jarno@ovn.org>
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
    • Jarno Rajahalme's avatar
      ofp-actions: Style fixes. · 1dc4232e
      Jarno Rajahalme authored
      Replace a tab by a space and remove an unnecessary variable.
      Signed-off-by: default avatarJarno Rajahalme <jarno@ovn.org>
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
    • Jarno Rajahalme's avatar
      upcall: Don't start new revalidation round too soon after the last one. · 5b5c07d7
      Jarno Rajahalme authored
      The execution time of 'ovs-ofctl add-flows' with a large number of
      flows can be more than halved if revalidators are not running after
      each flow mod separately.  This was first suspected when it was found
      that 'ovs-ofctl --bundle add-flows' is about 10 times faster than the
      same command without the '--bundle' option in a scenario where there
      is a large set of flows being added and no datapath flows at all.  One
      of the differences caused by the '--bundle' option is that the
      revalidators are woken up only once, at the end of the whole set of
      flow table changes, rather than after each flow table change
      This patch limits the revalidation to run at most 200 times a second
      by enforcing a minimum of 5ms time gap between the start times of
      revalidation rounds.  If nothing happens in, say 6 milliseconds, and
      then a new flow table change is signaled, the revalidator threads wake
      up immediately without any further delay.  Values smaller than 5 were
      found to increase the 'ovs-ofctl add-flows' execution time noticeably.
      Since the revalidators are not running after each flow mod, the
      overall OVS CPU utilization during the 'ovs-ofctl add-flows' run time
      is reduced roughly by one core on a four core machine.
      In testing the 'ovs-ofctl add-flows' execution time is not
      significantly improved from this even if the revalidators are not
      notified about the flow table changes at all.
      Signed-off-by: default avatarJarno Rajahalme <jarno@ovn.org>
      Acked-by: default avatarBen Pfaff <blp@ovn.org>
    • David Hill's avatar
      netdev-linux: Use ethtool when miimon fails. · c5ce0709
      David Hill authored
      Some network drivers might return true to SIOCGMIIPHY and an error on
      SIOCGMIIREG when using MII to query phy state. Fall back to ethtool if this
      happens to allow failover to work when using such nics.
      Reported-at: http://openvswitch.org/pipermail/dev/2016-August/078800.htmlSigned-off-by: default avatarDavid Hill <dhill@redhat.com>
      Signed-off-by: default avatarJoe Stringer <joe@ovn.org>
    • Andy Zhou's avatar
      ovsdb: Fix memory leak when disposing 'replication_dbs' · 0f185980
      Andy Zhou authored
      Found by inspection.
      The 'replication_dbs' structure was not freed after use.
      Fix by adding a new function replication_dbs_destroy().
      Also remove unnecessary global pointer variables initializer.
      Signed-off-by: default avatarAndy Zhou <azhou@ovn.org>
      Acked-by: default avatarBen Pfaff <blp@ovn.org>
    • Andy Zhou's avatar
      ovsdb: Fix segfalut during replication. · 8b30ada4
      Andy Zhou authored
      The newly added replication logic makes it possible for a monitor to
      receive delete and insertion of the same row back to back, which
      was not possible before. Add logic (and comment) to handle this
      case to avoid follow crash reported by Valgrind:
          #0  0x0000000000453edd in ovsdb_datum_compare_3way
                  (a=0x5efbe60, b=0x0, type=0x5e6a848) at lib/ovsdb-data.c:1626
          #1  0x0000000000453ea4 in ovsdb_datum_equals
                  (a=0x5efbe60, b=0x0, type=0x5e6a848) at lib/ovsdb-data.c:1616
          #2  0x000000000041b651 in update_monitor_row_data
                  (mt=0x5eda4a0, row=0x5efbe00, data=0x0) at ovsdb/monitor.c:310
          #3  0x000000000041ed14 in ovsdb_monitor_changes_update
                  (old=0x0, new=0x5efbe00, mt=0x5eda4a0, changes=0x5ef7180)
                  at ovsdb/monitor.c:1255
          #4  0x000000000041f12e in ovsdb_monitor_change_cb
                  (old=0x0, new=0x5efbe00, changed=0x5efc218, aux_=0xffefff040)
                  at ovsdb/monitor.c:1339
          #5  0x000000000042ded9 in ovsdb_txn_for_each_change
                  (txn=0x5efbd90, cb=0x41ef50 <ovsdb_monitor_change_cb>,
                   aux=0xffefff040) at ovsdb/transaction.c:906
          #6  0x0000000000420155 in ovsdb_monitor_commit
                  (replica=0x5eda2c0, txn=0x5efbd90, durable=false)
                  at ovsdb/monitor.c:1553
          #7  0x000000000042dc04 in ovsdb_txn_commit_
                  (txn=0x5efbd90, durable=false) at ovsdb/transaction.c:868
          #8  0x000000000042ddd4 in ovsdb_txn_commit (txn=0x5efbd90, durable=false)
                  at ovsdb/transaction.c:893
          #9  0x0000000000422e0c in process_notification
                  (table_updates=0x5efad10, db=0x5e6bd40) at ovsdb/replication.c:575
          #10 0x0000000000420ff3 in replication_run () at ovsdb/replication.c:184
          #11 0x0000000000405cc8 in main_loop
                  (jsonrpc=0x5e67770, all_dbs=0xffefff3a0, unixctl=0x5ebd980,
                   remotes=0xffefff360, run_process=0x0, exiting=0xffefff3c0,
                  is_backup=0xffefff2de) at ovsdb/ovsdb-server.c:198
          #12 0x0000000000406edb in main (argc=1, argv=0xffefff550)
                  at ovsdb/ovsdb-server.c:429
      Reported-by: default avatarJoe Stringer <joe@ovn.org>
      Reported-at: http://openvswitch.org/pipermail/dev/2016-September/079315.htmlReported-by: default avatarAlin Serdean <aserdean@cloudbasesolutions.com>
      Reported-at: http://openvswitch.org/pipermail/dev/2016-September/079586.htmlCo-authored-by: default avatarJoe Stringer <joe@ovn.org>
      Signed-off-by: default avatarAndy Zhou <azhou@ovn.org>
      Acked-by: default avatarBen Pfaff <blp@ovn.org>
  3. 26 Sep, 2016 1 commit
  4. 25 Sep, 2016 1 commit
  5. 24 Sep, 2016 1 commit
  6. 23 Sep, 2016 9 commits
  7. 22 Sep, 2016 4 commits
  8. 21 Sep, 2016 4 commits
  9. 20 Sep, 2016 7 commits
  10. 19 Sep, 2016 3 commits
  11. 16 Sep, 2016 2 commits