[ovs-dev] How does ovs userpsace+dpdk handle the original data packet when it needs ARP request and waits for ARP reply?
Joo Kim
itsolution at gmail.com
Wed Mar 22 10:42:20 UTC 2017
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?
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 at entry=0x7fffffffa160, ofp_port=2,
xr=xr at entry=0x0,
check_stp=check_stp at 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 at entry=0x7fffffffa160,
out_xbundle=out_xbundle at entry=0xd96200,
vlan=vlan at entry=0) at ofproto/ofproto-dpif-xlate.c:1958
#4 0x00000000005d81f6 in xlate_normal_flood (ctx=ctx at entry
=0x7fffffffa160,
in_xbundle=in_xbundle at entry=0xd9b3e0, vlan=vlan at 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 at entry=0x7fffffffa160, port=<optimized
out>,
max_len=<optimized out>, may_packet_in=may_packet_in at entry=true)
at ofproto/ofproto-dpif-xlate.c:3981
#7 0x00000000005d51ee in do_xlate_actions (ofpacts=ofpacts at entry
=0xd99ae8,
ofpacts_len=ofpacts_len at entry=16, ctx=ctx at entry=0x7fffffffa160)
at ofproto/ofproto-dpif-xlate.c:4781
#8 0x00000000005da384 in xlate_actions (xin=xin at entry=0x7fffffffb770,
xout=xout at 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 at entry=0xd479b0, upcall=upcall at entry
=0x7fffffffbaa0,
odp_actions=odp_actions at entry=0x7fffffffc680, wc=wc at 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_ at entry
=0xdb8660,
flow=flow at entry=0x7fffffffcc10, wc=wc at entry=0x7fffffffce58,
ufid=ufid at entry=0x7fffffffc650,
type=type at entry=DPIF_UC_MISS, userdata=userdata at entry=0x0,
More information about the dev
mailing list