[ovs-git] [openvswitch/ovs] f673dc: upcall: Reuse flow_put initializer.

GitHub noreply at github.com
Thu Sep 1 20:22:15 UTC 2016


  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: f673dcd8c0fdbe71765d557c62c9aeab4b54c8f4
      https://github.com/openvswitch/ovs/commit/f673dcd8c0fdbe71765d557c62c9aeab4b54c8f4
  Author: Joe Stringer <joe at ovn.org>
  Date:   2016-09-01 (Thu, 01 Sep 2016)

  Changed paths:
    M ofproto/ofproto-dpif-upcall.c

  Log Message:
  -----------
  upcall: Reuse flow_put initializer.

Signed-off-by: Joe Stringer <joe at ovn.org>
Acked-by: Jarno Rajahalme <jarno at ovn.org>


  Commit: f3e8c44ef39255dec360540391e35c9e8f117816
      https://github.com/openvswitch/ovs/commit/f3e8c44ef39255dec360540391e35c9e8f117816
  Author: Joe Stringer <joe at ovn.org>
  Date:   2016-09-01 (Thu, 01 Sep 2016)

  Changed paths:
    M ofproto/ofproto-dpif-upcall.c

  Log Message:
  -----------
  upcall: Only init flow_put if ukey is installed.

Currently when processing a batch of upcalls, all datapath operations
are first initialized, then later the corresponding ukeys are installed.
If the ukey_install fails at this later point, then the code needs to
backtrack a bit to delete the ukey and skip using the initialized
datapath op.

It's a little simpler to only initialize the datapath operation if the
ukey could actually be installed. The locks are held longer, but these
locks aren't heavily contended and the extended holding of the lock will
be removed in a subsequent patch anyway.

Signed-off-by: Joe Stringer <joe at ovn.org>
Acked-by: Jarno Rajahalme <jarno at ovn.org>


  Commit: 54ebeff4c03d83fd8b8a61256af95524e757f640
      https://github.com/openvswitch/ovs/commit/54ebeff4c03d83fd8b8a61256af95524e757f640
  Author: Joe Stringer <joe at ovn.org>
  Date:   2016-09-01 (Thu, 01 Sep 2016)

  Changed paths:
    M ofproto/ofproto-dpif-upcall.c

  Log Message:
  -----------
  upcall: Track ukey states.

Ukeys have a defined lifetime that starts from being created, inserted
into the umaps, having the corresponding flow installed, then the flow
deleted, the ukey removed from the umap, rcu-deferral of its deletion,
and finally freedom.

However, until now it's all been represented behind a simple boolean
"flow_exists" with a bunch of implicit logic sprinkled around the
accessors. This patch attempts to make the ukey lifetime a bit clearer
by outlining the correct transitions and asserting that their lifetime
proceeds as expected.

This should improve the readability of the current code, and also make
the following patch easier to reason about.

Signed-off-by: Joe Stringer <joe at ovn.org>
Acked-by: Jarno Rajahalme <jarno at ovn.org>


  Commit: 67f08985d769468b112cb40a923cd75f3ee2c01a
      https://github.com/openvswitch/ovs/commit/67f08985d769468b112cb40a923cd75f3ee2c01a
  Author: Joe Stringer <joe at ovn.org>
  Date:   2016-09-01 (Thu, 01 Sep 2016)

  Changed paths:
    M ofproto/ofproto-dpif-upcall.c

  Log Message:
  -----------
  upcall: Replace ukeys for deleted flows.

If a revalidator dumps/revalidates a flow during the 'dump' phase,
resulting in the deletion of the flow, then the ukey state moves into
UKEY_EVICTED, and the ukey is kept around until the 'sweep' phase. The
ukey is kept around to ensure that cases like duplicated dumps from the
datapaths do not result in multiple attribution of the same stats.

However, if an upcall for this flow comes for a handler between the
revalidator 'dump' and 'sweep' phases, the handler will lookup the ukey
and find that the ukey exists, then skip installing a new flow entirely.
As a result, for this period all traffic for the flow is slowpathed.
If there is a lot of traffic hitting this flow, then it will all be
handled in userspace until the 'sweep' phase. Eventually the
revalidators will reach the sweep phase and delete the ukey, and
subsequently the handlers should install a new flow.

To reduce the slowpathing of this traffic during flow table transitions,
allow the handler to identify this case during miss upcall handling and
replace the existing ukey with a new ukey. The handler will then be able
to install a flow for this traffic, allowing the traffic flow to return
to the fastpath.

Signed-off-by: Joe Stringer <joe at ovn.org>
Acked-by: Jarno Rajahalme <jarno at ovn.org>


Compare: https://github.com/openvswitch/ovs/compare/7fa39c6b9376...67f08985d769


More information about the git mailing list