openvswitch / ovs-issues

Issue tracker repo for Open vSwitch
10 stars 3 forks source link

Does dequeue zero copy function support vxlan network? #181

Open guofengguang opened 4 years ago

guofengguang commented 4 years ago

There is a problem when I use dequeue zero copy function in vxlan network,OVS process crash. but in VLAN network, OVS can work normally; The reason for the problem is that when UDP encapsulates the message sent by the virtual machine, OVS directly throws an abort exception due to the source information error of the memory,the code as follows: dp_packet_resize__()->"switch (b->source)" hits "default"branch; switch (b->source) { case DPBUF_DPDK: OVS_NOT_REACHED(); case DPBUF_MALLOC: if (new_headroom == dp_packet_headroom(b)) { new_base = xrealloc(dp_packet_base(b), new_allocated); } else { new_base = xmalloc(new_allocated); dp_packet_copy(b, new_base, new_headroom, new_tailroom); free(dp_packet_base(b)); } break; case DPBUF_STACK: OVS_NOT_REACHED(); case DPBUF_STUB: b->source = DPBUF_MALLOC; new_base = xmalloc(new_allocated); dp_packet_copy(b, new_base, new_headroom, new_tailroom); break; default: OVS_NOT_REACHED(); } The stack information as follows:

0 0x00007f4c49379337 in raise () from /lib64/libc.so.6

1 0x00007f4c4937aa28 in abort () from /lib64/libc.so.6

2 0x0000000000904225 in dp_packet_resize__ (b=b@entry=0x61041d240, new_headroom=new_headroom@entry=64, new_tailroom=) at lib/dp-packet.c:259

3 0x00000000009045ff in dp_packet_prealloc_headroom (b=b@entry=0x61041d240, size=size@entry=50) at lib/dp-packet.c:289

4 0x0000000000904ae1 in dp_packet_push_uninit (b=b@entry=0x61041d240, size=size@entry=50) at lib/dp-packet.c:401

5 0x00000000009b9adc in netdev_tnl_push_ip_header (packet=packet@entry=0x61041d240, header=0x7f4c28014ea4, size=50, ip_tot_size=ip_tot_size@entry=0x7f4c36f31e5c) at lib/netdev-native-tnl.c:154

6 0x00000000009b9bd0 in netdev_tnl_push_udp_header (netdev=, packet=0x61041d240, data=) at lib/netdev-native-tnl.c:225

7 0x000000000093856c in netdev_push_header (netdev=0x3292fa0, batch=batch@entry=0x7f4c36f32bf0, data=data@entry=0x7f4c28014e94) at lib/netdev.c:862

8 0x00000000009115cc in push_tnl_action (batch=0x7f4c36f32bf0, attr=0x7f4c36f36010, pmd=0x7f4c36f36010) at lib/dpif-netdev.c:6894

9 dp_executecb (aux=aux@entry=0x7f4c36f33080, packets=packets_@entry=0x7f4c36f32bf0, a=a@entry=0x7f4c28014e90, should_steal=false) at lib/dpif-netdev.c:6991

10 0x0000000000940f28 in odp_execute_actions (dp=dp@entry=0x7f4c36f33080, batch=batch@entry=0x7f4c36f32bf0, steal=steal@entry=true, actions=, actions_len=actions_len@entry=80,

dp_execute_action=dp_execute_action@entry=0x910e90 <dp_execute_cb>) at lib/odp-execute.c:718

11 0x0000000000941ebc in odp_execute_clone (dp_execute_action=0x910e90 , actions=0x7f4c28014e8c, steal=, batch=0x7f4c36f32bf0, dp=0x7f4c36f33080) at lib/odp-execute.c:640

12 odp_execute_actions (dp=dp@entry=0x7f4c36f33080, batch=batch@entry=0x7f4c36f32bf0, steal=steal@entry=true, actions=, actions_len=,

dp_execute_action=dp_execute_action@entry=0x910e90 <dp_execute_cb>) at lib/odp-execute.c:847

13 0x000000000090f0b4 in dp_netdev_execute_actions (actions_len=, actions=, flow=0x7f4c2c0065c0, should_steal=true, packets=, pmd=0x7f4c36f36010)

at lib/dpif-netdev.c:7260

14 packet_batch_per_flow_execute (pmd=0x7f4c36f36010, batch=0x7f4c36f32be0) at lib/dpif-netdev.c:6250

15 dp_netdev_input__ (pmd=pmd@entry=0x7f4c36f36010, packets=packets@entry=0x7f4c36f33100, md_is_valid=md_is_valid@entry=false, port_no=port_no@entry=3) at lib/dpif-netdev.c:6755

16 0x000000000090fb52 in dp_netdev_input (port_no=3, packets=0x7f4c36f33100, pmd=0x7f4c36f36010) at lib/dpif-netdev.c:6764

17 dp_netdev_process_rxq_port (pmd=pmd@entry=0x7f4c36f36010, rxq=0x3297dd0, port_no=3) at lib/dpif-netdev.c:4274

18 0x000000000090ff05 in pmd_threadmain (f=) at lib/dpif-netdev.c:5447

19 0x000000000098e14d in ovsthreadwrapper (aux=) at lib/ovs-thread.c:353

20 0x00007f4c49c22e65 in start_thread () from /lib64/libpthread.so.0

21 0x00007f4c4944188d in clone () from /lib64/libc.so.6

igsilya commented 4 years ago

Hi. It was a long time since this question asked, but I'll try to answer anyway.

Current OVS code aborts execution in case there is no enough headroom to resize the packet allocated by DPDK. That is a known issue. It could be solved now, I think, by attaching external buffers, support for which appeared in DPDK 19.11, however this is not implemented. For now default headroom in DPDK mbufs is 128 bytes, this should be enough to push around 2 tunneling headers. It's unlikely that users will require more in a typical environment. Anyway this issue exists and should be fixed eventually.

For the dequeue zero-copy case it's a bit different, since mbufs are not allocated by OVS, i.e. OVS is not able to request headroom, and if the packet doesn't have headroom, OVS will abort execution while trying to resize packets. The possible workaround here is to force your DPDK application in guest to allocate enough headroom for mbufs it sends.

Also, note that dequeue zero-copy support is deprecated in DPDK 20.08 and will be removed in DPDK 20.11. So, it will not be available in OVS 2.15 release.

Similar previous discussion: https://patchwork.ozlabs.org/project/openvswitch/patch/1525719894-7168-1-git-send-email-anju.thomas@ericsson.com/ BTW, I fully agree that OVS should not abort execution in case of one packet it's not able to resize, so this is a point for future improvement.