Thanks Mark, I will check this. I am not using multi-queue and from this thread, they have already added a change in OVS to support older version of QEMU(queue 0 is enabled in OVS even if qemu doesnt send VRING_ENABLE), which is what helped me to use qemu 2.4.1 till OVS 2.5.9. are these threads related ? http://openvswitch.org/pipermail/dev/2016-March/068430.html
http://openvswitch.org/pipermail/dev/2016-March/068429.html netdev@ovs-netdev: lookups: hit:36049 missed:8819 lost:0 flows: 14 port 0: ovs-netdev (tap) port 1: br-dpdk0 (tap) port 2: br-dpdk1 (tap) port 3: dpdk0 (dpdk: configured_rx_queues=1, configured_tx_queues=5, mtu=1500, requested_rx_queues=1, requested_tx_queues=5) port 4: dpdk1 (dpdk: configured_rx_queues=1, configured_tx_queues=5, mtu=1500, requested_rx_queues=1, requested_tx_queues=5) port 5: vhost-1-0 (dpdkvhostuser: configured_rx_queues=1, configured_tx_queues=1, mtu=1500, requested_rx_queues=1, requested_tx_queues=1) port 6: vhost-1-1 (dpdkvhostuser: configured_rx_queues=1, configured_tx_queues=1, mtu=1500, requested_rx_queues=1, requested_tx_queues=1) [root@localhost ~]# ovs-appctl dpif-netdev/pmd-rxq-show pmd thread numa_id 0 core_id 1: isolated : false port: vhost-1-0 queue-id: 0 port: dpdk1 queue-id: 0 port: vhost-1-1 queue-id: 0 port: dpdk0 queue-id: 0 On Wed, Oct 26, 2016 at 9:05 PM, Kavanagh, Mark B <mark.b.kavan...@intel.com > wrote: > > > >Hi Mark, > > > >This commit is already part of 2.6.0 that i am using. Also, when i create > an port with > >mtu_request, it is creating with the expected mtu, no problems here. > > > >The issue i am facing is, i am not even able to run traffic through a > PHY-VM-PHY with the > >default MTU (mtu_request not used). > >I am just creating the dpdk and vhostuser ports without mtu_request and > all the packets are > >getting dropped at vhostuser port > > > >Working scenario: DPDK16.04 + OVS2.5.9 + qemu 2.4.1 - default MTU 1500 > >Non-working scenario: DPDK16.07 + OVS2.6.0 + qemu 2.4.1 - default MTU > 1500. > > > >When i reconfigure the default vhostuser mtu to a different value, packet > drop issue stop; > >Though issue pops up if the VM is rebooted. > >I am trying to find why the default config wouldn't work with the above > dpdk,ovs,qemu version > >? > > > >Also doing qemu upgrade is resolving the issue - DPDK16.07 + OVS2.6.0 + > qemu 2.6.2 - default > >MTU 1500. > >There are other dependencies for me in upgrading the qemu verson to > 2.6.2, so i am looking > >for a way to make it work with 2.4.1. > > I presume then that vhost user multiqueue support is the root cause here. > Try applying the following commit to your QEMU tree - I'm guessing that it > should resolve your issue: > > commit dc3db6adde329548771ab2addc2ef8376b2b8b32 > Author: Michael S. Tsirkin <m...@redhat.com> > Date: Mon Nov 16 18:40:18 2015 +0200 > > vhost-user: start/stop all rings > > We are currently only sending VRING_ENABLE message for the > first ring, > that's wrong: we must start/stop them all. > > Thanks, > Mark > > > > >Regards > >Kapil. > > > >On Wed, Oct 26, 2016 at 7:42 PM, Kavanagh, Mark B < > mark.b.kavan...@intel.com> wrote: > >> > >>Hi, > >> > >>Issue Setup: DPDK 16.07 + OVS 2.6.0 + qemu 2.4.1 : PHY-VM-PHY > >> > >>I am trying to upgrade from (DPDK16.04 + OVS2.5.9), to (DPDK16.07 + > OVS2.6.0) for jumbo > >frame > >>support. After the upgrade, all packets are getting dropped on the > vhostuser port. > >>The dpdk/vhost user ports used here has default MTU of 1500 and packets > are within the MTU > >>size. > >> > >>Upon few trails, i found configuring the mtu on the vhostuser port is > somehow fixing the > >drop > >>issue. Command used : ovs-vsctl set interface vhostuser1 > mtu_request=1400(to any value > >>works). > >>Though even with this, if i reboot the VM, again the drop issue shows up > and mtu has to be > >>reconfigured/changed on the vhost to get the traffic working. > >>Seems, modifying the mtu value on vhost is internally triggering > something which resolves > >the > >>drop issue. > >> > >>I upgraded the qemu to 2.6.2, which resolves the drop issue in the vhost > ports without any > >>changes to default MTU. > >>I suspect, if its some interop issue with qemu 2.4.1, after the addition > of jumbo frame > >>support in OVS 2.6.0. > >> > >>Some input on how to debug this will help. is there any dependency on > dpdk+ovs version with > >>qemu version ? > > > >Hi Kapil, > > > >You should update OvS to the following commit, which resolves the MTU > issue: > > > > commit 7c12e20006118e69a98f6840731ebf0c87582b4a > > Author: Daniele Di Proietto <diproiet...@vmware.com> > > Date: Mon Aug 29 19:01:13 2016 -0700 > > > > bridge: Honor 'mtu_request' when port is added. > > > > 'mtu_request' was honored only when the port was reconfigured, > not when > > the port was added. > > > > This commit fixes the problem and improves a testcase to detect > the bug. > > > >Hope this helps, > >Mark > > > >> > >>i wanted to try dpdk or ovs upgrade alone, instead of both, but it has > some build > >>dependencies, so i can't try that. > >>My earlier mail on this issue - https://www.mail- > >>archive.com/d...@openvswitch.org/msg71381.html . > >> > >>Regards > >>Kapil. > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
