similar to: [PATCH v2 2/2] virtio_net: fix race in RX VQ processing

virtio net called virtqueue_enable_cq on RX path after napi_complete, so with NAPI_STATE_SCHED clear - outside the implicit napi lock. This violates the requirement to synchronize virtqueue_enable_cq wrt virtqueue_add_buf. In particular, used event can move backwards, causing us to lose interrupts. In a debug build, this can trigger panic within START_USE. Jason Wang reports that he can trigger

virtio net called virtqueue_enable_cq on RX path after napi_complete, so with NAPI_STATE_SCHED clear - outside the implicit napi lock. This violates the requirement to synchronize virtqueue_enable_cq wrt virtqueue_add_buf. In particular, used event can move backwards, causing us to lose interrupts. In a debug build, this can trigger panic within START_USE. Jason Wang reports that he can trigger

On 07/08/2013 05:04 PM, Michael S. Tsirkin wrote: > virtio net called virtqueue_enable_cq on RX path after napi_complete, so > with NAPI_STATE_SCHED clear - outside the implicit napi lock. > This violates the requirement to synchronize virtqueue_enable_cq wrt > virtqueue_add_buf. In particular, used event can move backwards, > causing us to lose interrupts. > In a debug build,

Hello. On 08-07-2013 13:04, Michael S. Tsirkin wrote: > virtio net called virtqueue_enable_cq on RX path after napi_complete, so > with NAPI_STATE_SCHED clear - outside the implicit napi lock. > This violates the requirement to synchronize virtqueue_enable_cq wrt > virtqueue_add_buf. In particular, used event can move backwards, > causing us to lose interrupts. > In a debug

On Fri, 2013-07-12 at 23:13 +0200, Wolfram Gloger wrote: > Hi, > > Today I merged M. Tsirkin's patch v2 "virtio_net: fix race in RX VQ > processing": > > http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00503.html > > into 3.2.48 and lightly tested the result (vhost-net, virtio-disk > and 9pfs using virtio). This sounds like it could be suitable

On Fri, 2013-07-12 at 23:13 +0200, Wolfram Gloger wrote: > Hi, > > Today I merged M. Tsirkin's patch v2 "virtio_net: fix race in RX VQ > processing": > > http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00503.html > > into 3.2.48 and lightly tested the result (vhost-net, virtio-disk > and 9pfs using virtio). This sounds like it could be suitable

On Fri, Jul 31, 2015 at 06:25:17PM +0200, Eric Dumazet wrote: > From: Eric Dumazet <edumazet at google.com> > > Straightforward patch to add GRO processing to virtio_net. > > napi_complete_done() usage allows more aggressive aggregation, > opted-in by setting /sys/class/net/xxx/gro_flush_timeout > > Tested: > > Setting /sys/class/net/xxx/gro_flush_timeout to

On Wed, Oct 15, 2014 at 06:25:25PM +0800, Jason Wang wrote: > On 10/15/2014 06:18 PM, Michael S. Tsirkin wrote: > > On Wed, Oct 15, 2014 at 03:25:29PM +0800, Jason Wang wrote: > >> > Orphan skb in ndo_start_xmit() breaks socket accounting and packet > >> > queuing. This in fact breaks lots of things such as pktgen and several > >> > TCP optimizations.

On 10/15/2014 06:18 PM, Michael S. Tsirkin wrote: > On Wed, Oct 15, 2014 at 03:25:29PM +0800, Jason Wang wrote: >> > Orphan skb in ndo_start_xmit() breaks socket accounting and packet >> > queuing. This in fact breaks lots of things such as pktgen and several >> > TCP optimizations. And also make BQL can't be implemented for >> > virtio-net. >> >

On 10/15/2014 06:18 PM, Michael S. Tsirkin wrote: > On Wed, Oct 15, 2014 at 03:25:29PM +0800, Jason Wang wrote: >> > Orphan skb in ndo_start_xmit() breaks socket accounting and packet >> > queuing. This in fact breaks lots of things such as pktgen and several >> > TCP optimizations. And also make BQL can't be implemented for >> > virtio-net. >> >

From: Eric Dumazet <edumazet at google.com> Straightforward patch to add GRO processing to virtio_net. napi_complete_done() usage allows more aggressive aggregation, opted-in by setting /sys/class/net/xxx/gro_flush_timeout Tested: Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec, Rick Jones reported following results. One VM of each on a pair of OpenStack compute nodes with

From: Eric Dumazet <edumazet at google.com> Straightforward patch to add GRO processing to virtio_net. napi_complete_done() usage allows more aggressive aggregation, opted-in by setting /sys/class/net/xxx/gro_flush_timeout Tested: Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec, Rick Jones reported following results. One VM of each on a pair of OpenStack compute nodes with

Orphan skb in ndo_start_xmit() breaks socket accounting and packet queuing. This in fact breaks lots of things such as pktgen and several TCP optimizations. And also make BQL can't be implemented for virtio-net. This patch tries to solve this issue by enabling tx interrupt. To avoid introducing extra spinlocks, a tx napi was scheduled to free those packets. More tx interrupt mitigation

Orphan skb in ndo_start_xmit() breaks socket accounting and packet queuing. This in fact breaks lots of things such as pktgen and several TCP optimizations. And also make BQL can't be implemented for virtio-net. This patch tries to solve this issue by enabling tx interrupt. To avoid introducing extra spinlocks, a tx napi was scheduled to free those packets. More tx interrupt mitigation

On 10/15/2014 05:53 AM, Michael S. Tsirkin wrote: > On newer hosts that support delayed tx interrupts, > we probably don't have much to gain from orphaning > packets early. > > Based on patch by Jason Wang. > > Note: this will likely degrade performance for hosts without event idx > support. Various fallback options are available, including > orphaning

On Wed, Oct 15, 2014 at 03:25:29PM +0800, Jason Wang wrote: > Orphan skb in ndo_start_xmit() breaks socket accounting and packet > queuing. This in fact breaks lots of things such as pktgen and several > TCP optimizations. And also make BQL can't be implemented for > virtio-net. > > This patch tries to solve this issue by enabling tx interrupt. To > avoid introducing

Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able to be rescheduled within napi_complete_done() even in non-busypoll case, but virtnet_poll() always enabled interrupts before complete, and when napi was rescheduled within napi_complete_done() it did not disable interrupts. This caused more interrupts when event idx is disabled. According to commit cbdadbbf0c79

Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able to be rescheduled within napi_complete_done() even in non-busypoll case, but virtnet_poll() always enabled interrupts before complete, and when napi was rescheduled within napi_complete_done() it did not disable interrupts. This caused more interrupts when event idx is disabled. According to commit cbdadbbf0c79

On 2017?12?07? 13:09, Michael S. Tsirkin wrote: > On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: >> Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able >> to be rescheduled within napi_complete_done() even in non-busypoll case, >> but virtnet_poll() always enabled interrupts before complete, and when >> napi was rescheduled

On 2017?12?07? 13:09, Michael S. Tsirkin wrote: > On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: >> Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able >> to be rescheduled within napi_complete_done() even in non-busypoll case, >> but virtnet_poll() always enabled interrupts before complete, and when >> napi was rescheduled