1/ Pls provide a hexdump capture of the request and corresponding reply
packets.
2/ Also, I would check 2.10.4 or latest 2.10.
On 10/10/19, 7:51 AM, "ovs-discuss-boun...@openvswitch.org on behalf of
txfh2007 via discuss" <ovs-discuss-boun...@openvswitch.org on behalf of
ovs-discuss@openvswitch.org> wrote:
Hi all:
I was using OVS-DPDK(version 2.10-1), and I have found pinging
between two VMs on different compute nodes failed. I have checked my env
and found there is one node's NIC cannot strip CRC of a frame, the other
node's NIC is normal(I mean it can strip CRC ). And the reason of ping fail
is the icmp reply pkt (from node whose NIC cannot strip CRC) is marked as
invalid . So the icmp request From Node A is 64 bytes， but the icmp reply
>From Node B is 68 bytes(with 4 bytes CRC). And when doing "check_l4_icmp",
when we call csum task(in lib/csum.c). Gcc emits unaligned accessor error.
The backtrace is as below:
I just want to confirm if this phenomenon is reasonable?
Many thanks
Timo
get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
89 GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
(gdb) bt
#0 get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
#1 0x000000000075a584 in csum_continue (partial=0,
data_=0x7f2ad0b1ed5c, n=68) at lib/csum.c:46
#2 0x000000000075a552 in csum (data=0x7f2ad0b1ed5c, n=68) at
lib/csum.c:33
#3 0x00000000008ddf18 in check_l4_icmp (data=0x7f2ad0b1ed5c, size=68,
validate_checksum=true) at lib/conntrack.c:1638
#4 0x00000000008de650 in extract_l4 (key=0x7f32a20df120,
data=0x7f2ad0b1ed5c, size=68, related=0x7f32a20df15d, l3=0x7f2ad0b1ed48,
validate_checksum=true) at lib/conntrack.c:1888
#5 0x00000000008de90d in conn_key_extract (ct=0x7f32b42a2d98,
pkt=0x7f2ad0b1e9c0, dl_type=8, ctx=0x7f32a20df120, zone=4)
at lib/conntrack.c:1973
#6 0x00000000008dd49c in conntrack_execute (ct=0x7f32b42a2d98,
pkt_batch=0x7f32a20e08b0, dl_type=8, force=false, commit=false,
zone=4, setmark=0x0, setlabel=0x0, tp_src=0, tp_dst=0, helper=0x0,
nat_action_info=0x0, now=5395897849) at lib/conntrack.c:1318
#7 0x000000000076d651 in dp_execute_cb (aux_=0x7f32a20dfb00,
packets_=0x7f32a20e08b0, a=0x7f32a20e0ac8, should_steal=false)
at lib/dpif-netdev.c:6711
#8 0x00000000007b2d49 in odp_execute_actions (dp=0x7f32a20dfb00,
batch=0x7f32a20e08b0, steal=true, actions=0x7f32a20e0ac8,
actions_len=20, dp_execute_action=0x76ca60 <dp_execute_cb>) at
lib/odp-execute.c:726
#9 0x000000000076d71b in dp_netdev_execute_actions
(pmd=0x7f2a6e1ce010, packets=0x7f32a20e08b0, should_steal=true,
flow=0x7f32a20dfb60, actions=0x7f32a20e0ac8, actions_len=20) at
lib/dpif-netdev.c:6754
#10 0x000000000076b900 in handle_packet_upcall (pmd=0x7f2a6e1ce010,
packet=0x7f2ad0b1e9c0, key=0x7f32a20e1100,
actions=0x7f32a20e0a40, put_actions=0x7f32a20e0a80) at
lib/dpif-netdev.c:6056
#11 0x000000000076bdf0 in fast_path_processing (pmd=0x7f2a6e1ce010,
packets_=0x7f32a20e2b60, keys=0x7f32a20e10c0,
batches=0x7f32a20e0f90, n_batches=0x7f32a20e13c0, in_port=15) at
lib/dpif-netdev.c:6153
#12 0x000000000076c3df in dp_netdev_input__ (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e2b60, md_is_valid=true, port_no=0)
at lib/dpif-netdev.c:6230
#13 0x000000000076c4d4 in dp_netdev_recirculate (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e2b60) at lib/dpif-netdev.c:6265
#14 0x000000000076ceae in dp_execute_cb (aux_=0x7f32a20e1db0,
packets_=0x7f32a20e2b60, a=0x7f32a20e2d78, should_steal=true)
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-discuss&data=02%7C01%7Cdball%40vmware.com%7Ca4f3c8a6ba5e4a010cc208d74d915931%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637063158979473315&sdata=Iy09aVT10BlMDf%2FeEEJbDPAGlL%2BthPhK7p0kKxmUdc4%3D&reserved=0
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
