[ovs-dev] [PATCH] ofp-actions: Don't encode variable length fields using NXAST_REG_LOAD.

Ben Pfaff blp at nicira.com
Fri Aug 28 18:15:35 UTC 2015

On Thu, Aug 27, 2015 at 07:06:51PM -0700, Jesse Gross wrote:
> 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 dev mailing list