[ovs-git] [openvswitch/ovs] 3de9dd: dpif-netdev: Don't use metaflow to operate on user...

GitHub noreply at github.com
Thu Jul 30 02:03:22 UTC 2015


  Branch: refs/heads/userspace2
  Home:   https://github.com/openvswitch/ovs
  Commit: 3de9dde6dbdd60fe19574b0e4b1b22b4f04018af
      https://github.com/openvswitch/ovs/commit/3de9dde6dbdd60fe19574b0e4b1b22b4f04018af
  Author: Jesse Gross <jesse at nicira.com>
  Date:   2015-07-29 (Wed, 29 Jul 2015)

  Changed paths:
    M lib/dpif-netdev.c

  Log Message:
  -----------
  dpif-netdev: Don't use metaflow to operate on userspace datapath fields.

If ofproto-dpif installs a flow into the userspace datapath that doesn't
include a mask, we need to synthesize an exact match one. This is currently
done using the metaflow infrastructure, iterating over each field and
setting it to all ones.

There is a conceptual mismatch here because metaflow is operating on
OpenFlow fields, not datapath ones. Even though they are generally very
similar, there are subtle differences, which is why it is necessary to
fix up the input port mask.

With Geneve options, the mapping is much more complicated and so the
situation is worse. The first issue is that the metaflow to flow
mapping can change over time, so we would need to do more revalidation
to track this. In addition, an upcoming patch will completely disconnect
the option format between ofproto-dpif and dpif-netdev, so the values
written by metaflow don't make sense at all.

When megaflows are turned off, ofproto-dpif internally generates masks
using flow_wildcards_init_for_packet(). Since that's the same as what
we want to do here, we can just use that instead of metaflow.

Signed-off-by: Jesse Gross <jesse at nicira.com>


  Commit: 18162dadfdbc0035d81ee28e3f8d6a1aee10e002
      https://github.com/openvswitch/ovs/commit/18162dadfdbc0035d81ee28e3f8d6a1aee10e002
  Author: Jesse Gross <jesse at nicira.com>
  Date:   2015-07-29 (Wed, 29 Jul 2015)

  Changed paths:
    M lib/automake.mk
    M lib/dpif-netdev.c
    M lib/flow.c
    M lib/flow.h
    A lib/geneve.h
    M lib/meta-flow.c
    M lib/netdev-vport.c
    M lib/odp-execute.c
    M lib/odp-util.c
    M lib/odp-util.h
    M lib/packets.h
    M lib/tun-metadata.c
    M lib/tun-metadata.h
    M ofproto/ofproto-dpif-sflow.c
    M ofproto/ofproto-dpif-upcall.c
    M tests/tunnel-push-pop.at

  Log Message:
  -----------
  dpif-netdev: Translate Geneve options per-flow, not per-packet.

The kernel implementation of Geneve options stores the TLV option
data in the flow exactly as received, without any further parsing.
This is then translated to known options for the purposes of matching
on flow setup (which will then install a datapath flow in the form
the kernel is expecting).

The userspace implementation behaves a little bit differently - it
looks up known options as each packet is received. The reason for this
is there is a much tighter coupling between datapath and flow translation
and the representation is generally expected to be the same. This works
but it incurs work on a per-packet basis that could be done per-flow
instead.

This introduces a small translation step for Geneve packets between
datapath and flow lookup for the userspace datapath in order to
allow the same kind of processing that the kernel does.

There is a second benefit to this as well: for some operations it is
preferable to keep the options exactly as they were received on the wire,
which this enables. One example is that for packets that are executed from
ofproto-dpif-upcall to the datapath, this avoids the translation of
Geneve metadata. Since this conversion is potentially lossy (for unknown
options), keeping everything in the same format removes the possibility
of dropping options if the packet comes back up to userspace and the
Geneve option translation table has changed. To help with these types of
operations, most functions can understand both formats of data and seamlessly
do the right thing.

Signed-off-by: Jesse Gross <jesse at nicira.com>


Compare: https://github.com/openvswitch/ovs/compare/3de9dde6dbdd^...18162dadfdbc


More information about the git mailing list