| Message ID | 1468344599-11613-1-git-send-email-johnson.li@intel.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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-bounces@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.li@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
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-bounces@openvswitch.org] On Behalf Of Jan Scheurich Sent: Tuesday, July 19, 2016 3:46 PM To: Li, Johnson <johnson.li@intel.com>; dev@openvswitch.org Cc: Simon Horman <simon.horman@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-bounces@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.li@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
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.yang@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-bounces@openvswitch.org] On Behalf Of Jan > Scheurich > Sent: Tuesday, July 19, 2016 3:46 PM > To: Li, Johnson <johnson.li@intel.com>; dev@openvswitch.org > Cc: Simon Horman <simon.horman@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-bounces@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.li@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
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.scheurich@ericsson.com] Sent: Wednesday, July 20, 2016 11:07 PM To: Yang, Yi Y <yi.y.yang@intel.com>; Li, Johnson <johnson.li@intel.com>; dev@openvswitch.org Cc: Simon Horman <simon.horman@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.yang@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-bounces@openvswitch.org] On Behalf Of Jan > Scheurich > Sent: Tuesday, July 19, 2016 3:46 PM > To: Li, Johnson <johnson.li@intel.com>; dev@openvswitch.org > Cc: Simon Horman <simon.horman@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-bounces@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.li@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
Hi Yi, I am afraid that it will not be possible to avoid recirculation after pop_eth and pop_nsh in the last SFF. That switch will have to match on the inner packet headers to find out how to forward the decapsulated packet. (Unless, the classifier on ingress already encoded the egress port in the NSH metadata and there is no need to rewrite any of the inner packet fields (such as S/DMAC), but that would be a really exotic case). Let's get it working first and worry about possible optimization in the next step. The most frequent use case (intermediate SFF) should be our main concern. BTW: We are closely collaborating with your Intel OVS colleagues in Ireland to generally optimize the OVS DPDK datapath. Hopefully the speedup that we will get there more than compensates the 30% penalty we incur for recirculation. BR, Jan > -----Original Message----- > From: Yang, Yi Y [mailto:yi.y.yang@intel.com] > Sent: Thursday, 21 July, 2016 03:44 > 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 > > 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.scheurich@ericsson.com] > Sent: Wednesday, July 20, 2016 11:07 PM > To: Yang, Yi Y <yi.y.yang@intel.com>; Li, Johnson <johnson.li@intel.com>; > dev@openvswitch.org > Cc: Simon Horman <simon.horman@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.yang@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-bounces@openvswitch.org] On Behalf Of Jan > > Scheurich > > Sent: Tuesday, July 19, 2016 3:46 PM > > To: Li, Johnson <johnson.li@intel.com>; dev@openvswitch.org > > Cc: Simon Horman <simon.horman@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-bounces@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.li@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
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; }
Signed-off-by: Johnson Li <johnson.li@intel.com>