On 20 Jun 2019, at 23:58, William Tu wrote:
On Thu, Jun 20, 2019 at 1:26 AM Eelco Chaudron <echau...@redhat.com>
wrote:
On 20 Jun 2019, at 4:15, William Tu wrote:
The PVP test seems to work fine however after a while it stops
forwarding:
$ ovs-ofctl dump-flows ovs_pvp_br0
cookie=0x0, duration=8.510s, table=0, n_packets=1, n_bytes=1020,
in_port=eno1 actions=output:tapVM
So this means for the physical nic, there is no packet received.
I can reproduce similar issue using trex imix traffic.
I think it's an issue in the ixgbe driver. If you keep sending
traffic, then it's ok.
But if you run af_xdp, stop, and run it again. The ixgbe driver report
# dmesg
[272206.755287] ixgbe 0000:0d:00.0 eth3: initiating reset to clear Tx
work after link loss
[272206.820872] ixgbe 0000:0d:00.0 eth3: Reset adapter
[272207.484969] ixgbe 0000:0d:00.1 eth5: initiating reset to clear Tx
work after link loss
[272207.588880] ixgbe 0000:0d:00.1 eth5: Reset adapter
# ip link show // the device is DOWN
94: eth3: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 xdp
qdisc mq state DOWN mode DEFAULT group default qlen 1000
So at the traffic generator side, trex detects link down and stops
sending traffic.
When restart OVS which clears the AF_XDP/XDP program, the link is up
again,
and the trex resumes sending traffic.
The PVP script will not restart OVS, or reapply the config, or bring
down the link between the tests.
Just to be sure, I re-ran it, and checked the logging, but nothing of
the above.
In addition, the same test without the VM does not show the problem.
I think it’s the packets being forwarded to the VM and as it takes
time before they are released os causing some lockup. I’ll try to
figure out more details next week when testing your v13.
Cheers,
Eelco
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
