On Fri, Aug 28, 2015 at 11:15 AM, Ben Pfaff <b...@nicira.com> wrote: > 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>
Thanks, applied to master. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
