similar to: Re: Is fallback vhost_net to qemu for live migrate available？

Hi Qin, On Mon, Aug 26, 2013 at 10:32 PM, Qin Chuanyu <qinchuanyu@huawei.com> wrote: > Hi all > > I am participating in a project which try to port vhost_net on Xen。 Neat! > By change the memory copy and notify mechanism ，currently virtio-net with > vhost_net could run on Xen with good performance。 I think the key in doing this would be to implement a property ioeventfd

On Wed, Feb 12, 2014 at 03:38:18PM +0800, Qin Chuanyu wrote: > another question is that vhost_zerocopy_callback is called by kfree_skb, > it may called in different thread context. > vhost_poll_queue is called decided by ubufs->kref.refcount, this may > cause there isn't any thread call vhost_poll_queue, but at least > one is needed. and this cause network break. > We

On 02/12/2014 03:38 PM, Qin Chuanyu wrote: > On 2013/8/30 12:29, Jason Wang wrote: >> We used to poll vhost queue before making DMA is done, this is racy >> if vhost >> thread were waked up before marking DMA is done which can result the >> signal to >> be missed. Fix this by always poll the vhost thread before DMA is done. >> >> Signed-off-by: Jason

On Wed, Feb 26, 2014 at 03:11:21PM +0800, Jason Wang wrote: > On 02/26/2014 02:32 PM, Qin Chuanyu wrote: > >On 2014/2/26 13:53, Jason Wang wrote: > >>On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: > >>>On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: > >>>>We used to stop the handling of tx when the number of pending DMAs >

On 02/26/2014 05:23 PM, Michael S. Tsirkin wrote: > On Wed, Feb 26, 2014 at 03:11:21PM +0800, Jason Wang wrote: >> > On 02/26/2014 02:32 PM, Qin Chuanyu wrote: >>> > >On 2014/2/26 13:53, Jason Wang wrote: >>>> > >>On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: >>>>> > >>>On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason

On 02/26/2014 05:23 PM, Michael S. Tsirkin wrote: > On Wed, Feb 26, 2014 at 03:11:21PM +0800, Jason Wang wrote: >> > On 02/26/2014 02:32 PM, Qin Chuanyu wrote: >>> > >On 2014/2/26 13:53, Jason Wang wrote: >>>> > >>On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: >>>>> > >>>On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason

On 02/26/2014 02:32 PM, Qin Chuanyu wrote: > On 2014/2/26 13:53, Jason Wang wrote: >> On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: >>> On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >>>> We used to stop the handling of tx when the number of pending DMAs >>>> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation

On 02/26/2014 02:32 PM, Qin Chuanyu wrote: > On 2014/2/26 13:53, Jason Wang wrote: >> On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: >>> On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >>>> We used to stop the handling of tx when the number of pending DMAs >>>> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation

The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to d3d665a654a35c47463d2aa6353bac3ce293f4f5: vhost-scsi: whitespace tweak (2013-09-17 22:56:09 +0300)

From: Jason Wang <jasowang at redhat.com> Date: Fri, 7 Mar 2014 13:28:27 +0800 > This is because the delay added by htb may lead the delay the finish > of DMAs and cause the pending DMAs for tap0 exceeds the limit > (VHOST_MAX_PEND). In this case vhost stop handling tx request until > htb send some packets. The problem here is all of the packets > transmission were blocked

The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to d3d665a654a35c47463d2aa6353bac3ce293f4f5: vhost-scsi: whitespace tweak (2013-09-17 22:56:09 +0300)

vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing

vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing

This fixes a deadlock with vhost reported in the field, as well as a theoretical race issue found by code review. Patches 1+2 are needed for stable. Thanks to Qin Chuanyu for reporting the issue! Michael S. Tsirkin (3): kref: add kref_sub_return vhost: fix ref cnt checking deadlock vhost: fix a theoretical race in device cleanup include/linux/kref.h | 33

This fixes a deadlock with vhost reported in the field, as well as a theoretical race issue found by code review. Patches 1+2 are needed for stable. Thanks to Qin Chuanyu for reporting the issue! Michael S. Tsirkin (3): kref: add kref_sub_return vhost: fix ref cnt checking deadlock vhost: fix a theoretical race in device cleanup include/linux/kref.h | 33

On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: > We used to stop the handling of tx when the number of pending DMAs > exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation > of both host and guest. But it was too aggressive in some cases, since > any delay or blocking of a single packet may delay or block the guest > transmission. Consider the following

On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: > On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >> We used to stop the handling of tx when the number of pending DMAs >> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation >> of both host and guest. But it was too aggressive in some cases, since >> any delay or blocking of a single packet

On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: > On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >> We used to stop the handling of tx when the number of pending DMAs >> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation >> of both host and guest. But it was too aggressive in some cases, since >> any delay or blocking of a single packet

We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-----+ +-----+ | VM1 | | VM2 | +--+--+

We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-----+ +-----+ | VM1 | | VM2 | +--+--+