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 <je...@nicira.com>
Acked-by: Ben Pfaff <b...@nicira.com> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
