[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