On 14 Jan 2020, at 12:23, Stokes, Ian wrote:
On 1/13/2020 8:32 PM, Stokes, Ian wrote:
<SNIP>
Hi Eelco, I'm seeing a crash in OVS while running this with just a
port and a default queue 0 (phy to phy setup). It seems related to the
call to rte_meter_trtcm_rfc4115_color_blind_check. I've provided more
detail below in the trtcm_policer_run_single_packet function, just
wondering if you've come across it?
Heres the output for the qos configuration I'm using
-bash-4.4$ovs-appctl -t ovs-vswitchd qos/show dpdk1
QoS: dpdk1 trtcm-policer
eir: 52000
cbs: 2048
ebs: 2048
cir: 52000
Default:
eir: 52000
cbs: 2048
ebs: 2048
cir: 52000
tx_packets: 672150
tx_bytes: 30918900
tx_errors: 489562233
I'll try to investigate further with DPDK and GDB also.
I tried to replicate this, but I’m not able to do so. How did you
test? Reconfiguring it and start, etc. etc.?
<SNIP>
A few times during testing I have seen OVS crash with the following
./launch_vswitch.sh: line 66: 11694 Floating point exception sudo
$OVS_DIR/vswitchd/ovs-vswitchd unix:$DB_SOCK --pidfile
Looking into it with GDB it sems related to the
rte_meter_trtcm_rfc4115_color_blind_check above. See GDB output below.
Thread 12 "pmd-c03/id:9" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7f3dce734700 (LWP 26465)]
0x0000000000d4b92d in rte_meter_trtcm_rfc4115_color_blind_check
(m=0x328e178, p=0x328e148, time=29107058565136113, pkt_len=46) at
/opt/istokes/dpdk-19.11//x86_64-native-linuxapp-gcc/include/rte_meter.h:599
599 n_periods_te = time_diff_te / p->eir_period;
(gdb) bt
#0 0x0000000000d4b92d in rte_meter_trtcm_rfc4115_color_blind_check
(m=0x328e178, p=0x328e148, time=29107058565136113, pkt_len=46) at
/opt/istokes/dpdk-19.11//x86_64-native-linuxapp-gcc/include/rte_meter.h:599
#1 0x0000000000d4abc1 in trtcm_policer_run_single_packet
(policer=0x2774200, pkt=0x1508fbd40, time=29107058565136113) at
lib/netdev-dpdk.c:4649
#2 0x0000000000d4ad24 in trtcm_policer_run (conf=0x2774200,
pkts=0x7f3db8005100, pkt_cnt=32, should_steal=true) at
lib/netdev-dpdk.c:4691
#3 0x0000000000d45299 in netdev_dpdk_qos_run (dev=0x17fd68840,
pkts=0x7f3db8005100, cnt=32, should_steal=true) at
lib/netdev-dpdk.c:2421
#4 0x0000000000d45db0 in netdev_dpdk_send__ (dev=0x17fd68840, qid=1,
batch=0x7f3db80050f0, concurrent_txq=false) at lib/netdev-dpdk.c:2683
#5 0x0000000000d45ee9 in netdev_dpdk_eth_send (netdev=0x17fd688c0,
qid=1, batch=0x7f3db80050f0, concurrent_txq=false) at
lib/netdev-dpdk.c:2710
#6 0x0000000000c342ba in netdev_send (netdev=0x17fd688c0, qid=1,
batch=0x7f3db80050f0, concurrent_txq=false) at lib/netdev.c:814
#7 0x0000000000beb3de in dp_netdev_pmd_flush_output_on_port
(pmd=0x7f3dce735010, p=0x7f3db80050c0) at lib/dpif-netdev.c:4224
#8 0x0000000000beb5c4 in dp_netdev_pmd_flush_output_packets
(pmd=0x7f3dce735010, force=false) at lib/dpif-netdev.c:4264
#9 0x0000000000beb814 in dp_netdev_process_rxq_port
(pmd=0x7f3dce735010, rxq=0x328d930, port_no=2) at
lib/dpif-netdev.c:4319
#10 0x0000000000bef432 in pmd_thread_main (f_=0x7f3dce735010) at
lib/dpif-netdev.c:5556
#11 0x0000000000cb24e5 in ovsthread_wrapper (aux_=0x326d220) at
lib/ovs-thread.c:383
#12 0x00007f3de11d236d in start_thread (arg=0x7f3dce734700) at
pthread_create.c:456
#13 0x00007f3de06bab4f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Looks like a divide by zero, but that was fixed and seems to be in DPDK
v19.11, ebe3a769911071450acb808153ec2a2496726906
So for some reason rte_meter_get_tb_params() might return 0 in
eir_period. Looking at the code, I would say this could only really
happen if rte_get_tsc_hz() returns 0, which seems odd… Could this
happen in your system for some reason?
//Eelco
<SNIP>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev