On Tue, May 8, 2018 at 7:36 PM, Kevin Traynor <[email protected]> wrote:
> On 05/08/2018 09:19 AM, Christian Ehrhardt wrote: > > > > > > On Thu, May 3, 2018 at 6:22 PM, Stokes, Ian <[email protected] > > <mailto:[email protected]>> wrote: > > > > > On 05/02/2018 11:16 AM, Maxime Coquelin wrote: > > > > Hi Ian, > > > > > > > > On 05/02/2018 11:42 AM, Stokes, Ian wrote: > > > >>> On 04/25/2018 10:17 AM, Stokes, Ian wrote: > > > >>>>> Modify travis linux build script to use the latest DPDK > stable > > > >>>>> release 17.11.2. Update docs for latest DPDK stable releases. > > > >>>>> > > > >>>> > > > >>>> Thanks for this Kevin, I'm lining this up for the next pull > request. > > > >>>> > > > >>> > > > >>> Thanks - note, this is relevant for master and branch-2.9. > > > >>> > > > >> > > > >> Hi Kevin, > > > >> > > > >> I was running validation for the this week's pull request and I > > > >> spotted vhost reconnect was failing. > > > >> > > > >> I traced it back to the move to 17.11.2. > > > >> > > > >> The test case is a vm running testpmd forwarding traffic in p2p. > > > >> > > > >> The vswitch itself is reset so traffic stops arriving to the vm, > > > >> after restarting the vswitch reconnects to the VM. At this point > > > >> testpmd within the VM segfaults. > > > >> > > > > > > Thanks for finding it. Which version of guest DPDK and QEMU do you > use? > > > Also what are settings for rx mergable buffers, vIOMMU, MTU, num > queues? > > > > Sorry for the delay, wanted to do a little more testing. > > > > DPDK 17.11.2 (on both host and guest.) > > QEMU 2.9.1. > > Mergable buffer off. > > vIOMMU disabled. > > MTU=1500. > > Single queue for vhost interfaces. > > > > For completeness the QEMU argument vsperf uses for launching the VM > > is below. I didn’t see anything out of place myself. > > > > /bin/bash', '-c', 'sudo -E taskset -c 6,7 > > /opt/istokes/qemu/x86_64-softmmu/qemu-system-x86_64 -m 2048 -smp 2 > > -cpu host,migratable=off -drive > > if=scsi,file=/opt/istokes/vm_images/vsperf_img1.qcow2 -boot c > > --enable-kvm -monitor unix:/tmp/vm0monitor,server,nowait -object > > memory-backend-file,id=mem,size=2048M,mem-path=/dev/ > hugepages,share=on > > -numa node,memdev=mem -mem-prealloc -nographic -vnc :0 -name Client0 > > -snapshot -net none -no-reboot -drive > > if=scsi,format=raw,file=fat:rw:/tmp/qemu0_share,snapshot=off > > -chardev > > socket,id=char0,path=/usr/local/var/run/openvswitch/ > dpdkvhostuserclient0,server > > -netdev type=vhost-user,id=net1,chardev=char0,vhostforce -device > > virtio-net-pci,mac=00:00:00:00:00:01,netdev=net1,csum=off, > mrg_rxbuf=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off > > -chardev > > socket,id=char1,path=/usr/local/var/run/openvswitch/ > dpdkvhostuserclient1,server > > -netdev type=vhost-user,id=net2,chardev=char1,vhostforce -device > > virtio-net-pci,mac=00:00:00:00:00:02,netdev=net2,csum=off, > mrg_rxbuf=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off' > > > > In testing I swapped to QEMU 2.7.1 and in that case the test passes > > without issue using 17.11.2 (same setup as above). > > > > > > Hi Ian, > > I wanted to ask if there was progress on this outside of this mail > thread? > > We were holding back the otherwise ready CVE on DPDK due to this, but I > > can't reproduce the hang on my own. > > So I was wondering if I might have missed updates on this topic that > > were sent somewhere else? > > > > Hi Christian, I talked with Maxime and it looks to be a QEMU bug > introduced in QEMU 2.9 and fixed in QEMU 2.11/2.10.2 [1]. It doesn't > appear to be caused by DPDK 17.11.2. I guess Ian will run through his > test system when he is back in the office. > This is just the update I needed. Waiting for Ian then, to be back and verify the commit fixes it for the qemu versions being affected at the moment. Thank you Kevin! > Kevin. > > [1] > https://git.qemu.org/?p=qemu.git;a=commit;h=2ae39a113af311cb56a0c35b7f212d > afcef15303 > > > > Ian > > > > > > >> Doing a git bisect on DPDK 17.11.2 the issue occurs with commit > > > >> > > > >> vhost: fix indirect descriptors table translation size > (a0d990b19) > > > > > > > > I would be surprised the problem comes from this patch. > > > > I guess your are testing without vIOMMU enabled> If this is the > > case, > > > > then the size parameter isn't used at the time of this patch: > > > > > > > > static __rte_always_inline uint64_t > > > > vhost_iova_to_vva(struct virtio_net *dev, struct vhost_virtqueue > > *vq, > > > > uint64_t iova, uint64_t size, uint8_t perm) { > > > > if (!(dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))) > > > > return rte_vhost_gpa_to_vva(dev->mem, iova); > > > > > > > > return __vhost_iova_to_vva(dev, vq, iova, size, perm); } > > > > > > > > So I fail to see how it could cause any regression. > > > > > > > > Regards, > > > > Maxime > > > > > > > >> Just wondering if you see similar behavior in testing? > > > >> > > > >> Regards > > > >> Ian > > > >> > > > >> > > > > _______________________________________________ > > dev mailing list > > [email protected] <mailto:[email protected]> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > > > > > > > > > > -- > > Christian Ehrhardt > > Software Engineer, Ubuntu Server > > Canonical Ltd > > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
