Hi Yi, Recirculation is implicitly triggered by calling ctx_trigger_freeze(ctx) at the end of the composition phase of an action.
The example for this is pop_mpls, but unfortunately it is a bit hidden there because the invocation of ctx_trigger_freeze(ctx) is deferred in order to avoid unnecessary recirculation of the decapsulated packet, for example when it is directly sent out to a port. (For the background see http://openvswitch.org/pipermail/dev/2016-May/071657.html) Instead compose_mpls_pop_action() sets ctx->was_mpls = true and subsequent actions that do require recirculation to happen check the was_mpls flag and call ctx_trigger_freeze(ctx) when needed. An example is xlate_select_group(). For pop_nsh and pop_eth you should not worry about such complications and call ctx_trigger_freeze(ctx) directly after having modified the flow according to the pop action (have a look at flow_pop_mpls() function in flow.c for an idea how to do this). BR, Jan > -----Original Message----- > From: Yang, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Wednesday, 20 July, 2016 04:00 > To: Jan Scheurich; Li, Johnson; dev@openvswitch.org > Cc: Simon Horman > Subject: RE: [ovs-dev] [RFC PATCH v2 12/13] Commit push_eth/pop_eth flow > action to data plane > > Hi, Jan > > How do you know we trigger recirculate after pop_eth? pop_nsh also needs > to do so, is there any existing example for reference? > > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan > Scheurich > Sent: Tuesday, July 19, 2016 3:46 PM > To: Li, Johnson <johnson...@intel.com>; dev@openvswitch.org > Cc: Simon Horman <simon.hor...@netronome.com> > Subject: Re: [ovs-dev] [RFC PATCH v2 12/13] Commit push_eth/pop_eth > flow action to data plane > > Hi Johnson, > > After basing these patches on Simon's L3 tunneling support the push_eth > action should take the flow-> base_layer into account: > > If it is LAYER_2, pushing an Ethernet header encapsulates the inner L2 frame > and therefore requires a call to xlate_commit_actions(ctx) before composing > the push_eth action. We need to pick a specific "eth_type" for the resulting > L2 frame so that OVS can identify a raw Eth over Eth encapsulation and > handle it correctly at pop_eth (see below). A natural choice could be 0x6558 > used e.g. as protocol type for Transparent Ethernet Bridging (Ethernet over > GRE). > > If it is LAYER_3, push_eth just adds the missing MAC header to the "L3" > packet without encapsulating it. The ethertype remains unchanged. No need > to call xlate_commit_actions(ctx) in that case. > > For pop_eth there is a reverse problem (It is obviously only allowed if flow- > >base_layer is LAYER_2): > > If the eth_type of the L2 frame indicates a known "L3" payload, you only > remove the MAC header from the flow and change the base_layer to > LAYER_3. Supported "L3" eth_types would include MPLS, ARP, IPv4, IPv6, > NSH (anything else?). I am not sure how much sense it would make to > continue processing unknown eth_types as L3 packets in the pipeline. But > perhaps it won't do any harm either. > > If the eth_type is the chosen value for Eth over Eth (e.g. 0x6658), pop_eth > should trigger recirculation to reparse the inner L2 packet. In this case the > base_layer should remain LAYER_2. > > BR, Jan > > > -----Original Message----- > > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Johnson Li > > Sent: Tuesday, 12 July, 2016 19:30 > > To: dev@openvswitch.org > > Subject: [ovs-dev] [RFC PATCH v2 12/13] Commit push_eth/pop_eth flow > > action to data plane > > > > Signed-off-by: Johnson Li <johnson...@intel.com> > > > > diff --git a/ofproto/ofproto-dpif-xlate.c > > b/ofproto/ofproto-dpif-xlate.c index f5c1888..fb3cd2e 100644 > > --- a/ofproto/ofproto-dpif-xlate.c > > +++ b/ofproto/ofproto-dpif-xlate.c > > @@ -5129,8 +5129,17 @@ do_xlate_actions(const struct ofpact *ofpacts, > > size_t ofpacts_len, > > memset(&flow->nsh, 0x0, sizeof flow->nsh); > > nl_msg_put_flag(ctx->odp_actions, OVS_ACTION_ATTR_POP_NSH); > > break; > > - case OFPACT_PUSH_ETH: > > + case OFPACT_PUSH_ETH: { > > + struct ovs_action_push_eth eth; > > + > > + eth.addresses.eth_dst = flow->dl_dst; > > + eth.addresses.eth_src = flow->dl_src; > > + nl_msg_put_unspec(ctx->odp_actions, > > OVS_ACTION_ATTR_PUSH_ETH, > > + ð, sizeof eth); > > + break; > > + } > > case OFPACT_POP_ETH: > > + nl_msg_put_flag(ctx->odp_actions, > > + OVS_ACTION_ATTR_POP_ETH); > > break; > > } > > > > -- > > 1.8.4.2 > > > > -------------------------------------------------------------- > > Intel Research and Development Ireland Limited Registered in Ireland > > Registered Office: Collinstown Industrial Park, Leixlip, County > > Kildare Registered Number: 308263 > > > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev