similar to: [PATCH net-next V2] vhost_net: conditionally enable tx polling

On Tue, Oct 31, 2017 at 06:27:20PM +0800, Jason Wang wrote: > We always poll tx for socket, this is sub optimal since: > > - we only want to be notified when sndbuf is available > - this will slightly increase the waitqueue traversing time and more > important, vhost could not benefit from commit > commit 9e641bdcfa4e > ("net-tun: restructure tun_do_read for better

We always poll tx for socket, this is sub optimal since: - we only want to be notified when sndbuf is available - this will slightly increase the waitqueue traversing time and more important, vhost could not benefit from commit commit 9e641bdcfa4e ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency") even if we've stopped rx polling during handle_rx() since

We always poll tx for socket, this is sub optimal since: - we only want to be notified when sndbuf is available - this will slightly increase the waitqueue traversing time and more important, vhost could not benefit from commit commit 9e641bdcfa4e ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency") even if we've stopped rx polling during handle_rx() since

On Wed, Nov 01, 2017 at 08:51:36PM +0800, Jason Wang wrote: > > > On 2017?11?01? 00:36, Michael S. Tsirkin wrote: > > On Tue, Oct 31, 2017 at 06:27:20PM +0800, Jason Wang wrote: > > > We always poll tx for socket, this is sub optimal since: > > > > > > - we only want to be notified when sndbuf is available > > > - this will slightly increase

On 2017?11?01? 00:36, Michael S. Tsirkin wrote: > On Tue, Oct 31, 2017 at 06:27:20PM +0800, Jason Wang wrote: >> We always poll tx for socket, this is sub optimal since: >> >> - we only want to be notified when sndbuf is available >> - this will slightly increase the waitqueue traversing time and more >> important, vhost could not benefit from commit >>

On 2017?11?01? 00:36, Michael S. Tsirkin wrote: > On Tue, Oct 31, 2017 at 06:27:20PM +0800, Jason Wang wrote: >> We always poll tx for socket, this is sub optimal since: >> >> - we only want to be notified when sndbuf is available >> - this will slightly increase the waitqueue traversing time and more >> important, vhost could not benefit from commit >>

On Fri, Dec 01, 2017 at 05:10:37AM -0500, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > tun_recvmsg() supports accepting skb by msg_control after > commit ac77cfd4258f ("tun: support receiving skb through msg_control"), > the skb if presented should be freed no matter how far it can go > along, otherwise it would be leaked. > > This

From: Wei Xu <wexu at redhat.com> tun_recvmsg() supports accepting skb by msg_control after commit ac77cfd4258f ("tun: support receiving skb through msg_control"), the skb if presented should be freed no matter how far it can go along, otherwise it would be leaked. This patch fixes several missed cases. Signed-off-by: Wei Xu <wexu at redhat.com> Reported-by: Matthew Rosato

On Fri, Dec 01, 2017 at 03:11:05PM +0800, Jason Wang wrote: > > > On 2017?12?01? 13:54, wexu at redhat.com wrote: > > From: Wei Xu <wexu at redhat.com> > > > > Matthew found a roughly 40% tcp throughput regression with commit > > c67df11f(vhost_net: try batch dequing from skb array) as discussed > > in the following thread: > >

On Fri, Dec 01, 2017 at 03:11:05PM +0800, Jason Wang wrote: > > > On 2017?12?01? 13:54, wexu at redhat.com wrote: > > From: Wei Xu <wexu at redhat.com> > > > > Matthew found a roughly 40% tcp throughput regression with commit > > c67df11f(vhost_net: try batch dequing from skb array) as discussed > > in the following thread: > >

From: Wei Xu <wexu at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest

On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > Matthew found a roughly 40% tcp throughput regression with commit > c67df11f(vhost_net: try batch dequing from skb array) as discussed > in the following thread: > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > Eventually we figured

On 2017?12?01? 13:54, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > Matthew found a roughly 40% tcp throughput regression with commit > c67df11f(vhost_net: try batch dequing from skb array) as discussed > in the following thread: > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > Eventually we figured out that it was a skb

On Fri, Dec 01, 2017 at 05:10:36AM -0500, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > Matthew found a roughly 40% tcp throughput regression with commit > c67df11f(vhost_net: try batch dequing from skb array) as discussed > in the following thread: > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > Eventually we figured

On 2017?12?01? 13:54, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > tun_recvmsg() supports accepting skb by msg_control after > commit ac77cfd4258f ("tun: support receiving skb through msg_control"), > the skb if presented should be freed within the function, otherwise it > would be leaked. > > Signed-off-by: Wei Xu <wexu at

From: Wei Xu <wexu at redhat.com> Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread: https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html Eventually we figured out that it was a skb leak in handle_rx() when sending packets to the VM. This usually happens when a guest

On 2017?11?29? 22:23, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > Matthew found a roughly 40% tcp throughput regression with commit > c67df11f(vhost_net: try batch dequing from skb array) as discussed > in the following thread: > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > Eventually we figured out that it was a skb

On 2017?11?29? 23:31, Michael S. Tsirkin wrote: > On Wed, Nov 29, 2017 at 09:23:24AM -0500,wexu at redhat.com wrote: >> From: Wei Xu<wexu at redhat.com> >> >> Matthew found a roughly 40% tcp throughput regression with commit >> c67df11f(vhost_net: try batch dequing from skb array) as discussed >> in the following thread: >>

On 2017?11?29? 23:31, Michael S. Tsirkin wrote: > On Wed, Nov 29, 2017 at 09:23:24AM -0500,wexu at redhat.com wrote: >> From: Wei Xu<wexu at redhat.com> >> >> Matthew found a roughly 40% tcp throughput regression with commit >> c67df11f(vhost_net: try batch dequing from skb array) as discussed >> in the following thread: >>

On Wed, Nov 29, 2017 at 09:23:24AM -0500, wexu at redhat.com wrote: > From: Wei Xu <wexu at redhat.com> > > Matthew found a roughly 40% tcp throughput regression with commit > c67df11f(vhost_net: try batch dequing from skb array) as discussed > in the following thread: > https://www.mail-archive.com/netdev at vger.kernel.org/msg187936.html > > Eventually we figured