It's clear enough, thanks a lot, Jan But http://openvswitch.org/pipermail/dev/2016-May/071657.html also mentioned recirculate will result in 35% performance degradation, for SFC use case, this is really a serious issue, how do you think we can alleviate this very efficiently?
I think the performance is top one for SFC use case. -----Original Message----- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Wednesday, July 20, 2016 11:07 PM To: Yang, Yi Y <yi.y.y...@intel.com>; 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 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
