summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorWei Xu <wexu@redhat.com>2017-12-01 05:10:36 -0500
committerDavid S. Miller <davem@davemloft.net>2017-12-02 21:31:03 -0500
commit6e474083f3daf3a3546737f5d7d502ad12eb257c (patch)
tree6c2a96027995107c57d9039f8d373557bf7fd0bd /arch
parentfa935ca224b43031ee10c857d7535aaec85c83b2 (diff)
downloadop-kernel-dev-6e474083f3daf3a3546737f5d7d502ad12eb257c.zip
op-kernel-dev-6e474083f3daf3a3546737f5d7d502ad12eb257c.tar.gz
vhost: fix skb leak in handle_rx()
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@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 can not drain out vq as fast as vhost fills in, afterwards it sets off the traffic jam and leaks skb(s) which occurs as no headcount to send on the vq from vhost side. This can be avoided by making sure we have got enough headcount before actually consuming a skb from the batched rx array while transmitting, which is simply done by moving checking the zero headcount a bit ahead. Signed-off-by: Wei Xu <wexu@redhat.com> Reported-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud