similar to: [PATCH net-next] vhost_net: do not stall on zerocopy depletion

From: Willem de Bruijn <willemb at google.com> Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy-based transmission. Tested by sending two udp flows from guest to host, one with payload of

From: Willem de Bruijn <willemb at google.com> Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy-based transmission. Tested by sending two udp flows from guest to host, one with payload of

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <willemb at google.com> >> >> Vhost-net has a hard limit on the number of zerocopy skbs in flight. >> When reached, transmission stalls. Stalls cause latency, as well as >>

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <willemb at google.com> >> >> Vhost-net has a hard limit on the number of zerocopy skbs in flight. >> When reached, transmission stalls. Stalls cause latency, as well as >>

On Sun, Oct 01, 2017 at 08:09:30AM +0800, kbuild test robot wrote: > Hi Willem, > > [auto build test WARNING on net-next/master] > > url: https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/vhost_net-do-not-stall-on-zerocopy-depletion/20171001-054709 > reproduce: > # apt-get install sparse > make ARCH=x86_64 allmodconfig > make C=1

On Sun, Oct 01, 2017 at 08:09:30AM +0800, kbuild test robot wrote: > Hi Willem, > > [auto build test WARNING on net-next/master] > > url: https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/vhost_net-do-not-stall-on-zerocopy-depletion/20171001-054709 > reproduce: > # apt-get install sparse > make ARCH=x86_64 allmodconfig > make C=1

On 2017?08?31? 22:30, Willem de Bruijn wrote: >> Incomplete results at this stage, but I do see this correlation between >> flows. It occurs even while not running out of zerocopy descriptors, >> which I cannot yet explain. >> >> Running two threads in a guest, each with a udp socket, each >> sending up to 100 datagrams, or until EAGAIN, every msec. >>

On 2017?08?31? 22:30, Willem de Bruijn wrote: >> Incomplete results at this stage, but I do see this correlation between >> flows. It occurs even while not running out of zerocopy descriptors, >> which I cannot yet explain. >> >> Running two threads in a guest, each with a udp socket, each >> sending up to 100 datagrams, or until EAGAIN, every msec. >>

> @@ -461,6 +460,7 @@ static void handle_tx(struct vhost_net *net) > struct socket *sock; > struct vhost_net_ubuf_ref *uninitialized_var(ubufs); > bool zcopy, zcopy_used; > + int i, batched = VHOST_NET_BATCH; > > mutex_lock(&vq->mutex); > sock = vq->private_data; > @@ -475,6 +475,12 @@ static void handle_tx(struct

> @@ -461,6 +460,7 @@ static void handle_tx(struct vhost_net *net) > struct socket *sock; > struct vhost_net_ubuf_ref *uninitialized_var(ubufs); > bool zcopy, zcopy_used; > + int i, batched = VHOST_NET_BATCH; > > mutex_lock(&vq->mutex); > sock = vq->private_data; > @@ -475,6 +475,12 @@ static void handle_tx(struct

On 2017?09?28? 08:25, Willem de Bruijn wrote: > From: Willem de Bruijn <willemb at google.com> > > Vhost-net has a hard limit on the number of zerocopy skbs in flight. > When reached, transmission stalls. Stalls cause latency, as well as > head-of-line blocking of other flows that do not use zerocopy. > > Instead of stalling, revert to copy-based transmission. > >

On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: > From: Willem de Bruijn <willemb at google.com> > > Vhost-net has a hard limit on the number of zerocopy skbs in flight. > When reached, transmission stalls. Stalls cause latency, as well as > head-of-line blocking of other flows that do not use zerocopy. > > Instead of stalling, revert to copy-based

On 08/20/2013 10:48 AM, Jason Wang wrote: > On 08/16/2013 06:02 PM, Michael S. Tsirkin wrote: >> > On Fri, Aug 16, 2013 at 01:16:30PM +0800, Jason Wang wrote: >>> >> We used to limit the max pending DMAs to prevent guest from pinning too many >>> >> pages. But this could be removed since: >>> >> >>> >> - We have the

On 08/20/2013 10:48 AM, Jason Wang wrote: > On 08/16/2013 06:02 PM, Michael S. Tsirkin wrote: >> > On Fri, Aug 16, 2013 at 01:16:30PM +0800, Jason Wang wrote: >>> >> We used to limit the max pending DMAs to prevent guest from pinning too many >>> >> pages. But this could be removed since: >>> >> >>> >> - We have the

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 | +--+--+

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 | +--+--+

Hi all: This series tries to unify and simplify vhost codes especially for zerocopy. Plase review. Thanks Jason Wang (6): vhost_net: make vhost_zerocopy_signal_used() returns void vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used() vhost: switch to use vhost_add_used_n() vhost_net: determine whether or not to use zerocopy at one time vhost_net: poll vhost

Hi all: This series tries to unify and simplify vhost codes especially for zerocopy. Plase review. Thanks Jason Wang (6): vhost_net: make vhost_zerocopy_signal_used() returns void vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used() vhost: switch to use vhost_add_used_n() vhost_net: determine whether or not to use zerocopy at one time vhost_net: poll vhost