Re: [Qemu-devel] vhost-user breaks after 96a3d98.

[Jason Wang]

On 2017年01月04日 00:27, Michael S. Tsirkin wrote:
> On Tue, Jan 03, 2017 at 06:28:18PM +0800, Jason Wang wrote:
> > On 2017年01月03日 11:09, Jason Wang wrote:
> > > On 2016年12月30日 20:41, Flavio Leitner wrote:
> > > > Hi,
> > > >
> > > > While I was testing vhost-user using OVS 2.5 and DPDK 2.2.0 in the
> > > > host and testpmd dpdk 2.2.0 in the guest, I found that the commit
> > > > below breaks the environment and no packets gets into the guest.
> > > >
> > > > dpdk port --> OVS --> vhost-user --> guest --> testpmd
> > > >                            ^--- drops here         ^--- no packets here.
> > > >
> > > > commit 96a3d98d2cdbd897ff5ab33427aa4cfb94077665
> > > > Author: Jason Wang <address@hidden>
> > > > Date:   Mon Aug 1 16:07:58 2016 +0800
> > > >
> > > >       vhost: don't set vring call if no vector
> > > >            We used to set vring call fd unconditionally even if guest
> > > > driver does
> > > >       not use MSIX for this vritqueue at all. This will cause lots of
> > > >       unnecessary userspace access and other checks for drivers does
> > > > not use
> > > >       interrupt at all (e.g virtio-net pmd). So check and clean vring
> > > > call
> > > >       fd if guest does not use any vector for this virtqueue at
> > > >       all.
> > > > [...]
> > > >
> > > > Thanks,
> > > Hi Flavio:
> > >
> > > Thanks for reporting this issue, could this be a bug of vhost-user? (I
> > > believe virito-net pmd does not use interrupt for rx/tx at all)
> > >
> > > Anyway, will try to reproduce it.
> > Could not reproduce this issue on similar setups (the only difference is I
> > don't create dpdk port) with dpdk 16.11 and ovs.git HEAD. Suspect an issue
> > dpdk. Will try OVS 2.5 + DPDK 2.2.0.
> >
> > Thanks
> Possibly dpdk assumed that call fd must be present unconditionally.
> Limit this patch to when protocol is updated? add a new protocol flag?

If this is a bug of dpdk, I tend to fix it (or just disable this patch 
for vhost-user). I'm not sure whether or not it's worthwhile to add a 
new protocol flag which was used to tell qemu that bug X was fixed.

Thanks