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
