[ovs-git] [openvswitch/ovs] 4fe04a: ofp-actions: Don't encode variable length fields u...

GitHub noreply at github.com
Fri Aug 28 18:24:00 UTC 2015


  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: 4fe04a7e6ded9ec24b7379f6227d15d3ff4f577f
      https://github.com/openvswitch/ovs/commit/4fe04a7e6ded9ec24b7379f6227d15d3ff4f577f
  Author: Jesse Gross <jesse at nicira.com>
  Date:   2015-08-28 (Fri, 28 Aug 2015)

  Changed paths:
    M lib/ofp-actions.c

  Log Message:
  -----------
  ofp-actions: Don't encode variable length fields using NXAST_REG_LOAD.

Currently, when using an OpenFlow 1.0 connection to encode a
tunnel metadata set field action, a series of NXAST_REG_LOADs
are emitted. The result is something like this:

actions=load:0xa->NXM_NX_TUN_METADATA0[0..63],load:0->
NXM_NX_TUN_METADATA0[64..127],load:0->NXM_NX_TUN_METADATA0[128..191],
load:0->NXM_NX_TUN_METADATA0[192..255],load:0->NXM_NX_TUN_METADATA0
[256..319],load:0->NXM_NX_TUN_METADATA0[320..383],load:0->
NXM_NX_TUN_METADATA0[384..447],load:0->NXM_NX_TUN_METADATA0[448..511],
load:0->NXM_NX_TUN_METADATA0[512..575],load:0->NXM_NX_TUN_METADATA0
[576..639],load:0->NXM_NX_TUN_METADATA0[640..703],load:0->
NXM_NX_TUN_METADATA0[704..767],load:0->NXM_NX_TUN_METADATA0[768..831],
load:0->NXM_NX_TUN_METADATA0[832..895],load:0->NXM_NX_TUN_METADATA0
[896..959],load:0->NXM_NX_TUN_METADATA0[960..991]

This happens because tunnel metadata is seen as a maximum size field
and so many loads need to be emitted to cover the entire thing. Besides
being ugly (this shows up when using ovs-ofctl in the default
configuration), it exposes the internal size of the field. While this
shouldn't be an issue since specific protocol fields (such as Geneve
options) have fixed max sizes even if the OVS implementation is extended,
it's still not a great idea.

If we instead use NXAST_REG_LOAD2 in cases where there isn't a suitable
OpenFlow alternative, both problems are avoided:

actions=set_field:0xa->tun_metadata0

This prefers NXAST_REG_LOAD2 for variable length fields since they would
all generally have the same problems. In addition, since the concept of
this type of field is fairly new, there are no backwards compatibility
issues.

Signed-off-by: Jesse Gross <jesse at nicira.com>
Acked-by: Ben Pfaff <blp at nicira.com>




More information about the git mailing list