-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ovs-dpdk gre offload #3
Comments
Hi, as far as I remember the script adds dummy TC rule so the mlx5 driver can set gre entropy in the firmware. |
roidayan
pushed a commit
to roidayan/ovs-tests
that referenced
this issue
Nov 17, 2024
Service restart removes ports from the bridge, and on SimX this takes a while. Service stop/start/restart is done via ovs-ctl script, which after short wait just kills the ovs-vswitchd process that its trying to terminate, causing leaks on Simx. Below is a stack trace by gdb to show SIGTERM in middle of ovs cleanup. Instead ovs-vsctl set port and service restart so it will take affect, add the required port options at configuration and remove the service restart. gdb stack trace Thread 1 "ovs-vswitchd" received signal SIGTERM, Terminated. 0x0000000001681686 in rte_spinlock_lock (sl=0x11802d18f8) at ../lib/eal/x86/include/rte_spinlock.h:28 28 asm volatile ( (gdb) #0 0x0000000001681686 in rte_spinlock_lock (sl=0x11802d18f8) at ../lib/eal/x86/include/rte_spinlock.h:28 Mellanox#1 0x00000000016a0acf in mlx5_hws_cnt_pool_destroy (sh=0x11802d0fc0, cpool=0x11bc7ffdc0) at ../drivers/net/mlx5/mlx5_hws_cnt.c:725 Mellanox#2 0x00000000015f4191 in __flow_hw_resource_release (dev=0x799ed80 <rte_eth_devices>, ctx_close=false) at ../drivers/net/mlx5/mlx5_flow_hw.c:12351 Mellanox#3 0x00000000015f5acb in flow_hw_resource_release (dev=0x799ed80 <rte_eth_devices>) at ../drivers/net/mlx5/mlx5_flow_hw.c:12843 Mellanox#4 0x00000000005d8182 in mlx5_dev_close (dev=0x799ed80 <rte_eth_devices>) at ../drivers/net/mlx5/mlx5.c:2448 #5 0x0000000001c3e14e in rte_eth_dev_close (port_id=0) at ../lib/ethdev/rte_ethdev.c:1605 #6 0x0000000001f892ce in ovs_doca_dev_close (dev_data=0x11802d2bd0) at lib/ovs-doca.c:1463 #7 0x0000000001f4487b in netdev_dpdk_destruct (netdev=0x11802d2880) at lib/netdev-dpdk.c:1670 #8 0x0000000001e2992c in netdev_destroy (dev=0x11802d2880) at lib/netdev.c:605 #9 0x0000000001e29a14 in netdev_unref (dev=0x11802d2880) at lib/netdev.c:632 #10 0x0000000001e29a40 in netdev_close (netdev=0x11802d2880) at lib/netdev.c:643 #11 0x0000000001d3c137 in ofport_destroy__ (port=0x9183cc0) at ofproto/ofproto.c:2664 #12 0x0000000001d3c198 in ofport_destroy (port=0x9183cc0, del=false) at ofproto/ofproto.c:2673 #13 0x0000000001d3a047 in ofproto_destroy (p=0x94d86e0, del=false) at ofproto/ofproto.c:1777 #14 0x0000000001d2a57d in bridge_destroy (br=0x94d8060, del=false) at vswitchd/bridge.c:3623 #15 0x0000000001d21a09 in bridge_exit (delete_datapath=false) at vswitchd/bridge.c:556 #16 0x0000000001d2f2ef in main (argc=12, argv=0x7ffe4ce5bd68) at vswitchd/ovs-vswitchd.c:149 Issue: 3965553 Change-Id: Ia80346d9f1ca24d73b247dde9e505639b47dbb5e Signed-off-by: Paul Blakey <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I encounter some problems with ovs-dpdk gre offload.
Can you tell me what the function of the script
ovs-dpdk-tests/tcgre.sh
? @roidayanThe issue is fixed when i run the tcgre.sh. But i dont kown why this script works ?
===> The issue i encountered as follows:
[root@10-65-115-105 ~]# ovs-vsctl list o
_uuid : 17067027-6321-4752-8bf8-a5b5319464a7
bridges : [5645efe2-6919-4bea-9e3c-23af5994cc64, d216814e-9902-4150-83d5-ce8d1f7e4896]
cur_cfg : 64
datapath_types : [netdev, system]
datapaths : {}
db_version : "8.3.1"
doca_initialized : false
doca_version : none
dpdk_initialized : true
dpdk_version : "MLNX_DPDK 22.11.1.4.2"
external_ids : {hostname="10-65-115-105", rundir="/var/run/openvswitch", system-id="1f69387d-1d70-4227-a1e5-2ba17fd3b4f0"}
iface_types : [bareudp, dpdk, dpdkvdpa, dpdkvhostuser, dpdkvhostuserclient, erspan, geneve, gre, gtpu, internal, ip6erspan, ip6gre, lisp, patch, stt, system, tap, vxlan]
manager_options : []
next_cfg : 64
other_config : {dpdk-extra="-a 0000:04:00.0,representor=[0-7],dv_flow_en=1,dv_esw_en=1,dv_xmeta_en=3 --log-level=mlx5,8", dpdk-hugepage-dir="/dev/hugepages", dpdk-init="true", dpdk-lcore-mask="0x2", dpdk-socket-mem="4096,4096", hw-offload="true", max-idle="10000", pmd-cpu-mask="0xC"}
ovs_version : "2.17.7-e054917"
ssl : []
statistics : {}
system_type : centos
system_version : "7"
[root@10-65-115-105 ~]# ovs-vsctl show
17067027-6321-4752-8bf8-a5b5319464a7
Bridge br0
datapath_type: netdev
Port br0
Interface br0
type: internal
Port gre0
Interface gre0
type: gre
options: {key="0x1122", local_ip="1.1.1.105", remote_ip="1.1.1.115"}
Port pf0vf1
Interface pf0vf1
type: dpdk
options: {dpdk-devargs="0000:04:00.0,representor=[1]"}
Port pf0vf0
Interface pf0vf0
type: dpdk
options: {dpdk-devargs="0000:04:00.0,representor=[0]"}
Bridge br-phy
fail_mode: standalone
datapath_type: netdev
Port p0
Interface p0
type: dpdk
options: {dpdk-devargs="0000:04:00.0"}
Port br-phy
Interface br-phy
type: internal
ovs_version: "2.17.7-e054917"
[root@10-65-115-105 ~]# ovs-ofctl dump-flows br0
cookie=0x0, duration=797.564s, table=0, n_packets=171, n_bytes=16758, in_port=pf0vf0 actions=output:gre0
[root@10-65-115-105 ~]# ovs-ofctl dump-flows br-phy
cookie=0x0, duration=1001.953s, table=0, n_packets=383, n_bytes=57704, priority=0 actions=NORMAL
[root@10-65-115-105 ~]# ovs-vsctl list br br0
_uuid : 5645efe2-6919-4bea-9e3c-23af5994cc64
auto_attach : []
controller : []
datapath_id : "0000e2ef4556ea4b"
datapath_type : netdev
datapath_version : ""
external_ids : {}
fail_mode : []
flood_vlans : []
flow_tables : {}
ipfix : []
mcast_snooping_enable: false
mirrors : []
name : br0
netflow : []
other_config : {}
ports : [360b9972-0eb3-4668-945e-4317458eeda2, 448c5eb5-06ec-4be6-aab3-89461686c03a, 74626751-b43c-4687-a3f5-8519737e5a20, 9223592e-05de-4c55-8141-c03c0b528f9b]
protocols : []
rstp_enable : false
rstp_status : {}
sflow : []
status : {}
stp_enable : false
[root@10-65-115-105 ~]#
[root@10-65-115-105 ~]# ovs-vsctl list br br-phy
_uuid : d216814e-9902-4150-83d5-ce8d1f7e4896
auto_attach : []
controller : []
datapath_id : "00001c34da5f3394"
datapath_type : netdev
datapath_version : ""
external_ids : {bridge-id=br-phy}
fail_mode : standalone
flood_vlans : []
flow_tables : {}
ipfix : []
mcast_snooping_enable: false
mirrors : []
name : br-phy
netflow : []
other_config : {hwaddr="1c:34:da:5f:33:94"}
ports : [24991499-66a1-4ef1-b696-4d8a70397c42, 9b5b5188-1686-40a4-af22-d94a91444ef6]
protocols : []
rstp_enable : false
rstp_status : {}
sflow : []
status : {}
stp_enable : false
sender vm
[root@sriov-vm-1 ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 6a:a7:9a:66:01:59 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.10/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::68a7:9aff:fe66:159/64 scope link
valid_lft forever preferred_lft forever
[root@sriov-vm-1 ~]# arp -n
Address HWtype HWaddress Flags Mask Iface
10.10.10.11 ether b6:32:6e:70:2e:db CM eth0
[root@sriov-vm-1 ~]# ping 10.10.10.11
===> 1st pkt key is right,but the 2nd pkt and the subsequent pkt key all wrong (the lower 8bit is wrong)
[root@10-65-115-105 ~]# ovs-appctl dpctl/dump-flows --names type=offloaded
flow-dump from pmd on cpu core: 2
recirc_id(0),in_port(pf0vf0),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(tos=0/0x3,frag=no), packets:7, bytes:686, used:0.496s, actions:clone(tnl_push(tnl_port(gre_sys),header(size=42,type=3,eth(dst=b8:59:9f:27:47:44,src=1c:34:da:5f:33:94,dl_type=0x0800),ipv4(src=1.1.1.105,dst=1.1.1.115,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x2000,proto=0x6558),key=0x1122)),out_port(br-phy)),p0)
[root@10-65-115-115 ~]# tcpdump -nnei enp8s0f0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp8s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
^[[O11:26:53.271328 1c:34:da:5f:33:94 > b8:59:9f:27:47:44, ethertype IPv4 (0x0800), length 140: 1.1.1.105 > 1.1.1.115: GREv0, key=0x1122, proto TEB (0x6558), length 106: 6a:a7:9a:66:01:59 > b6:32:6e:70:2e:db, ethertype IPv4 (0x0800), length 98: 10.10.10.10 > 10.10.10.11: ICMP echo request, id 5503, seq 1, length 64
11:26:53.271351 b8:59:9f:27:47:44 > 1c:34:da:5f:33:94, ethertype IPv4 (0x0800), length 168: 1.1.1.115 > 1.1.1.105: ICMP 1.1.1.115 protocol 47 unreachable, length 134
11:26:54.271069 1c:34:da:5f:33:94 > b8:59:9f:27:47:44, ethertype IPv4 (0x0800), length 140: 1.1.1.105 > 1.1.1.115: GREv0, key=0x118a, proto TEB (0x6558), length 106: 6a:a7:9a:66:01:59 > b6:32:6e:70:2e:db, ethertype IPv4 (0x0800), length 98: 10.10.10.10 > 10.10.10.11: ICMP echo request, id 5503, seq 2, length 64
11:26:54.271082 b8:59:9f:27:47:44 > 1c:34:da:5f:33:94, ethertype IPv4 (0x0800), length 168: 1.1.1.115 > 1.1.1.105: ICMP 1.1.1.115 protocol 47 unreachable, length 134
The text was updated successfully, but these errors were encountered: