On 3/22/17, 3:42 AM, "ovs-dev-boun...@openvswitch.org on behalf of Joo Kim" <ovs-dev-boun...@openvswitch.org on behalf of itsolut...@gmail.com> wrote:
Hello, In OVS2.6 userspace datapath code, when there is no ARP cache, looks like it sends ARP request on the fly (via tnl_send_arp_request() ). Then, until ARP reply is received later, what happens to the original data packet? Is it queued and sent later once ARP resolution is made ? Or just dropped? The original packet is dropped. BTW, I see following stack trace for the original packet, where build_tunnel_send() can send ARP request... #0 build_tunnel_send (xport=0xdbab10, tunnel_odp_port=3, flow=0x7fffffffb778, ctx=0x7fffffff9ac0) at ofproto/ofproto-dpif-xlate.c:2946 #1 compose_output_action__ (ctx=ctx@entry=0x7fffffffa160, ofp_port=2, xr=xr@entry=0x0, check_stp=check_stp@entry=true) at ofproto/ofproto-dpif-xlate.c:3243 #2 0x00000000005d7bb2 in compose_output_action (xr=0x0, ofp_port=<optimized out>, ctx=0x7fffffffa160) at ofproto/ofproto-dpif-xlate.c:3308 #3 output_normal (ctx=ctx@entry=0x7fffffffa160, out_xbundle=out_xbundle@entry=0xd96200, vlan=vlan@entry=0) at ofproto/ofproto-dpif-xlate.c:1958 #4 0x00000000005d81f6 in xlate_normal_flood (ctx=ctx@entry =0x7fffffffa160, in_xbundle=in_xbundle@entry=0xd9b3e0, vlan=vlan@entry=0) at ofproto/ofproto-dpif-xlate.c:2401 #5 0x00000000005d89ad in xlate_normal (ctx=0x7fffffffa160) at ofproto/ofproto-dpif-xlate.c:2604 #6 xlate_output_action (ctx=ctx@entry=0x7fffffffa160, port=<optimized out>, max_len=<optimized out>, may_packet_in=may_packet_in@entry=true) at ofproto/ofproto-dpif-xlate.c:3981 #7 0x00000000005d51ee in do_xlate_actions (ofpacts=ofpacts@entry =0xd99ae8, ofpacts_len=ofpacts_len@entry=16, ctx=ctx@entry=0x7fffffffa160) at ofproto/ofproto-dpif-xlate.c:4781 #8 0x00000000005da384 in xlate_actions (xin=xin@entry=0x7fffffffb770, xout=xout@entry=0x7fffffffbb00) at ofproto/ofproto-dpif-xlate.c:5618 #9 0x00000000005cec3c in upcall_xlate (wc=0x7fffffffce58, odp_actions=0x7fffffffc680, upcall=0x7fffffffbaa0, udpif=0xd479b0) at ofproto/ofproto-dpif-upcall.c:1102 #10 process_upcall (udpif=udpif@entry=0xd479b0, upcall=upcall@entry =0x7fffffffbaa0, odp_actions=odp_actions@entry=0x7fffffffc680, wc=wc@entry =0x7fffffffce58) at ofproto/ofproto-dpif-upcall.c:1239 #11 0x00000000005cf3ad in upcall_cb (packet=<optimized out>, flow=0x7fffffffcc10, ufid=<optimized out>, pmd_id=<optimized out>, type=<optimized out>, userdata=<optimized out>, actions=0x7fffffffc680, wc=0x7fffffffce58, put_actions=0x7fffffffc6c0, aux=0xd479b0) at ofproto/ofproto-dpif-upcall.c:1198 #12 0x00000000005f42f2 in dp_netdev_upcall (packet_=packet_@entry =0xdb8660, flow=flow@entry=0x7fffffffcc10, wc=wc@entry=0x7fffffffce58, ufid=ufid@entry=0x7fffffffc650, type=type@entry=DPIF_UC_MISS, userdata=userdata@entry=0x0, _______________________________________________ dev mailing list d...@openvswitch.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=dAp7C8khtZWfPGsspcroEJHGwaZFPmRopj68jLq0-Q4&s=u9BsulnRRZYP-diPy7cKhrzCLMBtlTtfk4QS-qj3cO4&e= _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev