search for: enable_cb_delay

...14 05:34 PM, Michael S. Tsirkin wrote: >>> On Wed, Oct 15, 2014 at 03:25:25PM +0800, Jason Wang wrote: >>>> This patch checks the new event idx to make sure used event idx never >>>> goes back. This is used to synchronize the calls between >>>> virtqueue_enable_cb_delayed() and virtqueue_enable_cb(). >>>> >>>> Cc: Rusty Russell <rusty at rustcorp.com.au> >>>> Cc: Michael S. Tsirkin <mst at redhat.com> >>>> Signed-off-by: Jason Wang <jasowang at redhat.com> >>> the implication being that mov...

...14 05:34 PM, Michael S. Tsirkin wrote: >>> On Wed, Oct 15, 2014 at 03:25:25PM +0800, Jason Wang wrote: >>>> This patch checks the new event idx to make sure used event idx never >>>> goes back. This is used to synchronize the calls between >>>> virtqueue_enable_cb_delayed() and virtqueue_enable_cb(). >>>> >>>> Cc: Rusty Russell <rusty at rustcorp.com.au> >>>> Cc: Michael S. Tsirkin <mst at redhat.com> >>>> Signed-off-by: Jason Wang <jasowang at redhat.com> >>> the implication being that mov...

...S. Tsirkin wrote: > >>> On Wed, Oct 15, 2014 at 03:25:25PM +0800, Jason Wang wrote: > >>>> This patch checks the new event idx to make sure used event idx never > >>>> goes back. This is used to synchronize the calls between > >>>> virtqueue_enable_cb_delayed() and virtqueue_enable_cb(). > >>>> > >>>> Cc: Rusty Russell <rusty at rustcorp.com.au> > >>>> Cc: Michael S. Tsirkin <mst at redhat.com> > >>>> Signed-off-by: Jason Wang <jasowang at redhat.com> > >>> the i...

...; > + __netif_tx_unlock(txq); >> > + if (unlikely(virtqueue_poll(sq->vq, r)) && > So you are enabling callback on the next packet, > which is almost sure to cause an interrupt storm > on the guest. > > > I think it's a bad idea, this is why I used > enable_cb_delayed in my patch. Right, will do this, but may also need to make sure used event never goes back since we may call virtqueue_enable_cb_avail(). > > >> > + napi_schedule_prep(napi)) { >> > + virtqueue_disable_cb(sq->vq); >> > + __napi_schedule(napi); >&g...

...; > + __netif_tx_unlock(txq); >> > + if (unlikely(virtqueue_poll(sq->vq, r)) && > So you are enabling callback on the next packet, > which is almost sure to cause an interrupt storm > on the guest. > > > I think it's a bad idea, this is why I used > enable_cb_delayed in my patch. Right, will do this, but may also need to make sure used event never goes back since we may call virtqueue_enable_cb_avail(). > > >> > + napi_schedule_prep(napi)) { >> > + virtqueue_disable_cb(sq->vq); >> > + __napi_schedule(napi); >&g...

...gt;> > + if (unlikely(virtqueue_poll(sq->vq, r)) && > > So you are enabling callback on the next packet, > > which is almost sure to cause an interrupt storm > > on the guest. > > > > > > I think it's a bad idea, this is why I used > > enable_cb_delayed in my patch. > > Right, will do this, but may also need to make sure used event never > goes back since we may call virtqueue_enable_cb_avail(). That's why my patch always calls virtqueue_enable_cb_delayed. So no need for hacks. Maybe you can review my patch and comment? >...

...acks (aka tx interrupts). Somewhat tested but I couldn't reproduce the original issues reported, sending out for help with testing. Wei, does this address the spurious interrupt issue you are observing? Could you confirm please? Thanks! changes from v2: Fixed a race condition in start_xmit: enable_cb_delayed was done as an optimization (to push out event index for split ring) so we did not have to care about it returning false (recheck). Now that we actually disable the cb we have to do test the return value and do the actual recheck. Michael S. Tsirkin (4): virtio_net: move tx vq operation u...

...acks (aka tx interrupts). Somewhat tested but I couldn't reproduce the original issues reported, sending out for help with testing. Wei, does this address the spurious interrupt issue you are observing? Could you confirm please? Thanks! changes from v2: Fixed a race condition in start_xmit: enable_cb_delayed was done as an optimization (to push out event index for split ring) so we did not have to care about it returning false (recheck). Now that we actually disable the cb we have to do test the return value and do the actual recheck. Michael S. Tsirkin (4): virtio_net: move tx vq operation u...

...(sq->vq); > + napi_complete(napi); > + __netif_tx_unlock(txq); > + if (unlikely(virtqueue_poll(sq->vq, r)) && So you are enabling callback on the next packet, which is almost sure to cause an interrupt storm on the guest. I think it's a bad idea, this is why I used enable_cb_delayed in my patch. > + napi_schedule_prep(napi)) { > + virtqueue_disable_cb(sq->vq); > + __napi_schedule(napi); > + goto again; > + } > + } else { > + __netif_tx_unlock(txq); > + } > + > + netif_wake_subqueue(vi->dev, vq2txq(sq->vq)); > + retur...

...freed. */ - skb_orphan(skb); - nf_reset(skb); - /* Apparently nice girls don't return TX_BUSY; stop the queue * before it gets out of hand. Naturally, this wastes entries. */ if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { netif_stop_subqueue(dev, qnum); if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { /* More just got used, free them then recheck. */ - free_old_xmit_skbs(sq); + free_old_xmit_skbs(sq, qsize); if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { netif_start_subqueue(dev, qnum); virtqueue_disable_cb(sq->vq); } } + } else if (virtqueue...

...freed. */ - skb_orphan(skb); - nf_reset(skb); - /* Apparently nice girls don't return TX_BUSY; stop the queue * before it gets out of hand. Naturally, this wastes entries. */ if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { netif_stop_subqueue(dev, qnum); if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { /* More just got used, free them then recheck. */ - free_old_xmit_skbs(sq); + free_old_xmit_skbs(sq, qsize); if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { netif_start_subqueue(dev, qnum); virtqueue_disable_cb(sq->vq); } } + } else if (virtqueue...

...: virtio: add api for delayed callbacks virtio_net: delay TX callbacks virtio_ring: Add capacity check API virtio_net: fix TX capacity checks using new API virtio_net: limit xmit polling This has some fixes that I posted previously applied, but otherwise ideantical to v1. I tried to change API for enable_cb_delayed as Rusty suggested but failed to do this. I think it's not possible to define cleanly. These work fine for me, I think they can be merged for 2.6.40 too but would be nice to hear back from Shirley, Tom, Krishna. III) There's also a patch that adds a tweak to virtio ring virtio: don'...

...: virtio: add api for delayed callbacks virtio_net: delay TX callbacks virtio_ring: Add capacity check API virtio_net: fix TX capacity checks using new API virtio_net: limit xmit polling This has some fixes that I posted previously applied, but otherwise ideantical to v1. I tried to change API for enable_cb_delayed as Rusty suggested but failed to do this. I think it's not possible to define cleanly. These work fine for me, I think they can be merged for 2.6.40 too but would be nice to hear back from Shirley, Tom, Krishna. III) There's also a patch that adds a tweak to virtio ring virtio: don'...

According to David, proper accounting and queueing (at all levels, not just TCP sockets) is more important than trying to skim a bunch of cycles by avoiding TX interrupts. Having an event to free the SKB is absolutely essential for the stack to operate correctly. This series tries to enable tx interrupt for virtio-net. The idea is simple: enable tx interrupt and schedule a tx napi to free old

According to David, proper accounting and queueing (at all levels, not just TCP sockets) is more important than trying to skim a bunch of cycles by avoiding TX interrupts. Having an event to free the SKB is absolutely essential for the stack to operate correctly. This series tries to enable tx interrupt for virtio-net. The idea is simple: enable tx interrupt and schedule a tx napi to free old