[ovs-git] [openvswitch/ovs] d1d781: ofproto-dpif-upcall: Translate input port as part ...

GitHub noreply at github.com
Mon Jun 13 20:45:39 UTC 2016


  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: d1d7816bec0ddc005e99df8d39c8c280ce8b4115
      https://github.com/openvswitch/ovs/commit/d1d7816bec0ddc005e99df8d39c8c280ce8b4115
  Author: Jesse Gross <jesse at kernel.org>
  Date:   2016-06-13 (Mon, 13 Jun 2016)

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

  Log Message:
  -----------
  ofproto-dpif-upcall: Translate input port as part of upcall translation.

When we generate wildcards for upcalled flows, the flows and therefore
the wildcards, are in OpenFlow format. These are mostly the same but
one exception is the input port. We work around this problem by simply
performing an exact match on the input port when generating netlink
formatted keys. (This does not lose any information in practice because
action translation also always exact matches on input port.)

While this works fine for kernel based flows, it misses the userspace
datapath, which directly consumes the OFP format mask for the input
port. The effect of this is that the in_port mask is sometimes only
the lower 16 bits of the field. (This is because OFP format is a 16-bit
value stored in a 32-bit field. The full width of the field is initialized
with an exact match mask but certain operations result in cleaving this
down to 16 bits.) In practice this does not cause a problem because datapath
port numbers are almost always in the lower 16 bits of the range anyways.

This moves the masking of the datapath format field to translation so that
all datapaths see the same result. This also makes more sense conceptually
as the input port in the flow is also in ODP format at this stage.

Signed-off-by: Jesse Gross <jesse at kernel.org>
Acked-by: Daniele Di Proietto <diproiettod at vmware.com>


  Commit: 098d2a9777f0d986220d278c0095eae42eaadf21
      https://github.com/openvswitch/ovs/commit/098d2a9777f0d986220d278c0095eae42eaadf21
  Author: Jesse Gross <jesse at kernel.org>
  Date:   2016-06-13 (Mon, 13 Jun 2016)

  Changed paths:
    M lib/dpif-netdev.c
    M lib/odp-util.c
    M lib/odp-util.h
    M lib/tnl-ports.c
    M ofproto/ofproto-dpif-upcall.c
    M tests/test-odp.c

  Log Message:
  -----------
  odp-util: Remove odp_in_port from struct odp_flow_key_parms.

When calling odp_flow_key_from_flow (or _mask), the in_port included
as part of the flow is ignored and must be explicitly passed as a
separate parameter. This is because the assumption was that the flow's
version would often be in OFP format, rather than ODP.

However, at this point all flows that are ready for serialization in
netlink format already have their in_port properly set to ODP format.
As a result, every caller needs to explicitly initialize the extra
paramter to the value that is in the flow. This switches to just use
the value in the flow to simply things and avoid the possibility of
forgetting to initialize the extra parameter.

Signed-off-by: Jesse Gross <jesse at kernel.org>
Acked-by: Daniele Di Proietto <diproiettod at vmware.com>


  Commit: 9044f2c11ff0021a9f5eb582ff25aa558dfa8a01
      https://github.com/openvswitch/ovs/commit/9044f2c11ff0021a9f5eb582ff25aa558dfa8a01
  Author: Jesse Gross <jesse at kernel.org>
  Date:   2016-06-13 (Mon, 13 Jun 2016)

  Changed paths:
    M lib/dpif-netdev.c
    M tests/dpif-netdev.at
    M tests/ofproto-dpif.at
    M tests/pmd.at

  Log Message:
  -----------
  dpif-netdev: Print installed flows in dpif format.

When debug logging is enabled, dpif-netdev can print each flow as it is
installed, which it currently does using OpenFlow match formatting. Compared
to ODP formatting, there generally isn't too much difference since the
fields are largely the same but it is inconsistent with other logging in
dpif-netdev as well as the analogous functions that deal with the kernel.

However, in some cases there is a difference between the two formats, such
as in the cases of input port or tunnel metadata. For input port, datapath
format helped detect that the generated masks were incorrect. As for tunnels,
at the moment, it's possible to convert between the two formats on demand as
we have a global metadata table. In the future, though this won't be possible
as the metadata table becomes per-bridge which the datapath won't have access
to.

Signed-off-by: Jesse Gross <jesse at kernel.org>
Acked-by: Daniele Di Proietto <diproiettod at vmware.com>


Compare: https://github.com/openvswitch/ovs/compare/968353c2d16c...9044f2c11ff0


More information about the git mailing list