On 10/13/2016 08:20 PM, Daniele Di Proietto wrote:
2016-10-13 10:33 GMT-07:00 Géza Gémes <geza.ge...@gmail.com
<mailto:geza.ge...@gmail.com>>:
2016-10-13 19:28 GMT+02:00 Géza Gémes <geza.ge...@gmail.com
<mailto:geza.ge...@gmail.com>>:
Hi,
Sorry for cross-posting, but I feel this might be an
interesting topic for the dev list as well.
I've recreated my setup with qemu VM instead of lxc container
and the situation is the same.
Summary of my setup:
Ovs compiled with dpdk (from ubuntu-cloud-archive/newton)
deployed on a libvirt VM having 3 network connections to a
shared network:
Szövegközi kép 3
I've set up two bridges: dpdk-br0 with dpdk and non-dpdk-br1
with kernel datapath each having an interface to the host
provided network. For both bridges only the normal action is
present, no flows were defined.
I forgot to mention, that intentionally I didn't use dpdkvhostuser
ports even with the dpdk datapath bridge as the problem I try to
investigate is whether there can be traffic in this scenario.
A symptom like the one you describe usually points to problem with
offloads.
When the userspace datapath receives packets from "system" devices,
the kernel might forward packets with wrong checksums, if offloads are
enabled.
Could you try to disable tx offloads inside the VM (or maybe on the
host, although there shouldn't be any problem with "internal"/"tap"
device)?
ethtool -K eth0 tx off
Thank you!
Disabling tx offload in the internal VM solved the tcp problem.
Cheers,
Geza
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
