On Thu, Jun 14, 2012 at 11:35:20PM -0700, Ben Pfaff wrote:
> OpenFlow actions have always been somewhat awkward to handle.
> Moreover, over time we've started creating actions that require more
> complicated parsing.  When we maintain those actions internally in
> their wire format, we end up parsing them multiple times, whenever
> we have to look at the set of actions.
> 
> When we add support for OpenFlow 1.1 or later protocols, the situation
> will get worse, because these newer protocols support many of the same
> actions but with different representations.  It becomes unrealistic to
> handle each protocol in its wire format.
> 
> This commit adopts a new strategy, by converting OpenFlow actions into
> an internal form from the wire format when they are read, and converting
> them back to the wire format when flows are dumped.  I believe that this
> will be more maintainable over time.
> 
> Signed-off-by: Ben Pfaff <[email protected]>

[snip]

> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index 5dcb3f0..bddb107 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c

[snip]

> @@ -5220,11 +5210,12 @@ struct xlate_reg_state {
>  
>  static void
>  xlate_autopath(struct action_xlate_ctx *ctx,
> -               const struct nx_action_autopath *naa)
> +               const struct ofpact_autopath *ap)
>  {
> -    uint16_t ofp_port = ntohl(naa->id);
> -    struct ofport_dpif *port = get_ofp_port(ctx->ofproto, ofp_port);
> +    struct ofport_dpif *port;
> +    uint32_t ofp_port;
>  
> +    port = get_ofp_port(ctx->ofproto, ap->port);
>      if (!port || !port->bundle) {
>          ofp_port = OFPP_NONE;
>      } else if (port->bundle->bond) {
> @@ -5235,7 +5226,7 @@ xlate_autopath(struct action_xlate_ctx *ctx,
>              ofp_port = slave->up.ofp_port;
>          }
>      }
> -    autopath_execute(naa, &ctx->flow, ofp_port);
> +    nxm_reg_load(&ap->dst, ofp_port, &ctx->flow);
>  }

GCC tells me that there are now cases where
ofp_port is not set.

[snip]
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

Reply via email to