| Message ID | CAH=CPzo_yW8dLwhEh98Pm3D76RMCFdsvbaZDYvR1g59FCyyK2g@mail.gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
Numan, This seems to be the right fix. In general, recirculations due to NXT_RESUME will fail if the packet metadata is not restored prior to the packet execution. Would you send a patch formatted by git format-patch with your Signed-off-by? Jarno > On May 9, 2016, at 1:55 AM, Numan Siddique <nusiddiq@redhat.com> wrote: > > The below fix is resolving the issue. But I am not sure if that's the right > solution. > May be the packet metadata should also be saved in "struct > ofputil_packet_in" in "emit_continuation()". > > --- > ofproto/ofproto-dpif.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c > index a1e0407..00369b6 100644 > --- a/ofproto/ofproto-dpif.c > +++ b/ofproto/ofproto-dpif.c > @@ -4399,6 +4399,7 @@ nxt_resume(struct ofproto *ofproto_, > struct dp_packet packet; > dp_packet_init(&packet, pin->public.packet_len); > dp_packet_put(&packet, pin->public.packet, pin->public.packet_len); > + pkt_metadata_from_flow(&packet.md, &pin->public.flow_metadata.flow); > > struct flow headers; > flow_extract(&packet, &headers); > -- > > Thanks > Numan > > > On Fri, May 6, 2016 at 6:35 PM, Numan Siddique <nusiddiq@redhat.com> wrote: > >> >> Thanks Babu for your comments. >> >> I am seeing the problem even if NXM_OF_IN_PORT is not set to zero after >> the packet is resumed. >> >> The issue is that a resumed packet is getting dropped when it executes the >> action 'OFPACT_CT'. >> 'xlate_lookup()' is failing in the 'upcall_receive()' >> >> Ben, if you want to reproduce the issue you can run the below commands >> >> Thanks >> Numan >> >> ----------------------------------------------------------------------- >> BRIDGE=ovs-test >> ovs-vsctl add-br $BRIDGE >> >> ovs-ofctl add-flow $BRIDGE >> "table=0,priority=1000,actions=controller(pause), resubmit(,1)" >> ovs-ofctl add-flow $BRIDGE "table=1,priority=1000,ip, >> actions=ct(table=2,zone=1)" >> ovs-ofctl add-flow $BRIDGE "table=1,priority=1000,arp, actions=FLOOD" >> ovs-ofctl add-flow $BRIDGE >> "table=2,priority=1000,actions=ct(commit,zone=1),resubmit(,3)" >> ovs-ofctl add-flow $BRIDGE "table=3,priority=1000,actions=NORMAL" >> >> ip netns add ns1 >> ip netns add ns2 >> >> ovs-vsctl add-port $BRIDGE tap1 -- set Interface tap1 type=internal >> ip link set tap1 netns ns1 >> ip netns exec ns1 ip link set dev tap1 up >> ip netns exec ns1 ip addr add 10.0.0.2/24 dev tap1 >> >> ovs-vsctl add-port $BRIDGE tap2 -- set Interface tap2 type=internal >> ip link set tap2 netns ns2 >> ip netns exec ns2 ip link set dev tap2 up >> ip netns exec ns2 ip addr add 10.0.0.3/24 dev tap2 >> >> # start ovs-ofctl monitor on $BRIDGE in another shell >> ovs-ofctl monitor $BRIDGE resume >> >> ip netns exec ns1 ping -c 1 10.0.0.3 >> ------------------------------------------------- >> >> >> >> >> >> >> >> >> On Thu, May 5, 2016 at 5:36 PM, Babu Shanmugam <bschanmu@redhat.com> >> wrote: >> >>> Numan, >>> It happens because flow chain is paused at the DHCP flow and while >>> resuming, the inport is set 0. When the packet traverse down the pipeline, >>> while processing an upcall for conntrack in the 49th table, a lookup for DP >>> inport 0 is performed and could not be found. Hence, it was not able to >>> proceed further. >>> >>> I think using packet-out with necessary actions in the userdata for >>> packet traversal would be better. We can use logical flow syntax such as >>> "output(inport)" to imply that the response is a packet-out to the inport >>> from which packet came. Suggestion are welcome. >>> >>> Thank you, >>> Babu >>> >>> >>> On Wednesday 13 April 2016 09:23 PM, Numan Siddique wrote: >>> >>>> Hi, >>>> >>>> I am seeing an issue while testing the ovn native dhcp implementation. >>>> >>>> When the dhcp reply packet from ovn-controller is resumed by >>>> ovs-vswitchd, >>>> the packet is getting dropped in the egress pipeline - ACL stage. >>>> >>>> I see the below messages in the vswitchd.log >>>> >>>> ------------------ >>>> >>>> 2016-04-13T14:14:03.813Z|00002|ofproto_dpif_upcall(handler1)|INFO|received >>>> packet on unassociated datapath port 0 >>>> >>>> 2016-04-13T14:14:03.860Z|00001|ofproto_dpif_upcall(revalidator2)|WARN|Failed >>>> to acquire udpif_key corresponding to unexpected flow (Invalid argument): >>>> ufid:a33e557f-369f-404e-aefb-2e3da678b09a >>>> ------------------------ >>>> >>>> >>>> In the function upcall_receive(), I could see that xlate_lookup() is >>>> returning error. >>>> >>>> Also I could see that in the function odp_flow_key_to_flow__() >>>> L5191, nl_attr_get_odp_port(attrs[OVS_KEY_ATTR_IN_PORT]) is returning 0. >>>> >>>> >>>> Please let me know if you need further information. >>>> >>>> Thanks >>>> Numan >>>> _______________________________________________ >>>> dev mailing list >>>> dev@openvswitch.org >>>> http://openvswitch.org/mailman/listinfo/dev >>>> >>> >>> >> > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev
Thanks Jarno, sure I will do that. On Tue, May 10, 2016 at 8:08 AM, Jarno Rajahalme <jarno@ovn.org> wrote: > Numan, > > This seems to be the right fix. In general, recirculations due to > NXT_RESUME will fail if the packet metadata is not restored prior to the > packet execution. > > Would you send a patch formatted by git format-patch with your > Signed-off-by? > > Jarno > > > On May 9, 2016, at 1:55 AM, Numan Siddique <nusiddiq@redhat.com> wrote: > > > > The below fix is resolving the issue. But I am not sure if that's the > right > > solution. > > May be the packet metadata should also be saved in "struct > > ofputil_packet_in" in "emit_continuation()". > > > > --- > > ofproto/ofproto-dpif.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c > > index a1e0407..00369b6 100644 > > --- a/ofproto/ofproto-dpif.c > > +++ b/ofproto/ofproto-dpif.c > > @@ -4399,6 +4399,7 @@ nxt_resume(struct ofproto *ofproto_, > > struct dp_packet packet; > > dp_packet_init(&packet, pin->public.packet_len); > > dp_packet_put(&packet, pin->public.packet, pin->public.packet_len); > > + pkt_metadata_from_flow(&packet.md, > &pin->public.flow_metadata.flow); > > > > struct flow headers; > > flow_extract(&packet, &headers); > > -- > > > > Thanks > > Numan > > > > > > On Fri, May 6, 2016 at 6:35 PM, Numan Siddique <nusiddiq@redhat.com> > wrote: > > > >> > >> Thanks Babu for your comments. > >> > >> I am seeing the problem even if NXM_OF_IN_PORT is not set to zero after > >> the packet is resumed. > >> > >> The issue is that a resumed packet is getting dropped when it executes > the > >> action 'OFPACT_CT'. > >> 'xlate_lookup()' is failing in the 'upcall_receive()' > >> > >> Ben, if you want to reproduce the issue you can run the below commands > >> > >> Thanks > >> Numan > >> > >> ----------------------------------------------------------------------- > >> BRIDGE=ovs-test > >> ovs-vsctl add-br $BRIDGE > >> > >> ovs-ofctl add-flow $BRIDGE > >> "table=0,priority=1000,actions=controller(pause), resubmit(,1)" > >> ovs-ofctl add-flow $BRIDGE "table=1,priority=1000,ip, > >> actions=ct(table=2,zone=1)" > >> ovs-ofctl add-flow $BRIDGE "table=1,priority=1000,arp, actions=FLOOD" > >> ovs-ofctl add-flow $BRIDGE > >> "table=2,priority=1000,actions=ct(commit,zone=1),resubmit(,3)" > >> ovs-ofctl add-flow $BRIDGE "table=3,priority=1000,actions=NORMAL" > >> > >> ip netns add ns1 > >> ip netns add ns2 > >> > >> ovs-vsctl add-port $BRIDGE tap1 -- set Interface tap1 type=internal > >> ip link set tap1 netns ns1 > >> ip netns exec ns1 ip link set dev tap1 up > >> ip netns exec ns1 ip addr add 10.0.0.2/24 dev tap1 > >> > >> ovs-vsctl add-port $BRIDGE tap2 -- set Interface tap2 type=internal > >> ip link set tap2 netns ns2 > >> ip netns exec ns2 ip link set dev tap2 up > >> ip netns exec ns2 ip addr add 10.0.0.3/24 dev tap2 > >> > >> # start ovs-ofctl monitor on $BRIDGE in another shell > >> ovs-ofctl monitor $BRIDGE resume > >> > >> ip netns exec ns1 ping -c 1 10.0.0.3 > >> ------------------------------------------------- > >> > >> > >> > >> > >> > >> > >> > >> > >> On Thu, May 5, 2016 at 5:36 PM, Babu Shanmugam <bschanmu@redhat.com> > >> wrote: > >> > >>> Numan, > >>> It happens because flow chain is paused at the DHCP flow and while > >>> resuming, the inport is set 0. When the packet traverse down the > pipeline, > >>> while processing an upcall for conntrack in the 49th table, a lookup > for DP > >>> inport 0 is performed and could not be found. Hence, it was not able to > >>> proceed further. > >>> > >>> I think using packet-out with necessary actions in the userdata for > >>> packet traversal would be better. We can use logical flow syntax such > as > >>> "output(inport)" to imply that the response is a packet-out to the > inport > >>> from which packet came. Suggestion are welcome. > >>> > >>> Thank you, > >>> Babu > >>> > >>> > >>> On Wednesday 13 April 2016 09:23 PM, Numan Siddique wrote: > >>> > >>>> Hi, > >>>> > >>>> I am seeing an issue while testing the ovn native dhcp implementation. > >>>> > >>>> When the dhcp reply packet from ovn-controller is resumed by > >>>> ovs-vswitchd, > >>>> the packet is getting dropped in the egress pipeline - ACL stage. > >>>> > >>>> I see the below messages in the vswitchd.log > >>>> > >>>> ------------------ > >>>> > >>>> > 2016-04-13T14:14:03.813Z|00002|ofproto_dpif_upcall(handler1)|INFO|received > >>>> packet on unassociated datapath port 0 > >>>> > >>>> > 2016-04-13T14:14:03.860Z|00001|ofproto_dpif_upcall(revalidator2)|WARN|Failed > >>>> to acquire udpif_key corresponding to unexpected flow (Invalid > argument): > >>>> ufid:a33e557f-369f-404e-aefb-2e3da678b09a > >>>> ------------------------ > >>>> > >>>> > >>>> In the function upcall_receive(), I could see that xlate_lookup() is > >>>> returning error. > >>>> > >>>> Also I could see that in the function odp_flow_key_to_flow__() > >>>> L5191, nl_attr_get_odp_port(attrs[OVS_KEY_ATTR_IN_PORT]) is > returning 0. > >>>> > >>>> > >>>> Please let me know if you need further information. > >>>> > >>>> Thanks > >>>> Numan > >>>> _______________________________________________ > >>>> 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.c b/ofproto/ofproto-dpif.c index a1e0407..00369b6 100644 --- a/ofproto/ofproto-dpif.c +++ b/ofproto/ofproto-dpif.c @@ -4399,6 +4399,7 @@ nxt_resume(struct ofproto *ofproto_, struct dp_packet packet; dp_packet_init(&packet, pin->public.packet_len); dp_packet_put(&packet, pin->public.packet, pin->public.packet_len); + pkt_metadata_from_flow(&packet.md, &pin->public.flow_metadata.flow); struct flow headers; flow_extract(&packet, &headers);