search for: netif_rx_reschedule

...00 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2) try_fill_recv(vi); - /* All done? */ - if (!skb) { + /* Out of packets? */ + if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->restart(vi->rvq)) && netif_rx_reschedule(vi->dev, napi))

...00 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2) try_fill_recv(vi); - /* All done? */ - if (!skb) { + /* Out of packets? */ + if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->restart(vi->rvq)) && netif_rx_reschedule(vi->dev, napi))

Hollis Blanchard wrote: > On Tue, 2008-03-25 at 14:45 +0100, Christian Ehrhardt wrote: >> => from one not yet defined point our guest seems to receive absolutely nothing >> => when the guest is hanging it sends nfs requests which are seen externally, but it does not seem to get the respones >> => the arp requests for the guest are repeated - maybe we can add some very

Hollis Blanchard wrote: > On Tue, 2008-03-25 at 14:45 +0100, Christian Ehrhardt wrote: >> => from one not yet defined point our guest seems to receive absolutely nothing >> => when the guest is hanging it sends nfs requests which are seen externally, but it does not seem to get the respones >> => the arp requests for the guest are repeated - maybe we can add some very

...;"; - print " no_work = vi->rvq->vq_ops->enable_cb(vi->rvq);"; print " netif_rx_complete(vi->dev);"; + print " no_work = vi->rvq->vq_ops->enable_cb(vi->rvq);"; print ""; print " if (!no_work && netif_rx_reschedule(vi->dev, received)) {"; print " skb = NULL;"; @@ -62,6 +62,32 @@ virtnet_poll = 1 } +/\tnetif_rx_schedule\(/ { + print "#ifdef COMPAT_napi"; + print " vi->rvq->vq_ops->enable_cb(vi->rvq);"; + print " if (netif_rx_schedule...

...============================================== --- kvm.orig/drivers/net/virtio_net.c +++ kvm/drivers/net/virtio_net.c @@ -203,8 +203,11 @@ again: if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->enable_cb(vi->rvq)) - && netif_rx_reschedule(vi->dev, napi)) + && napi_schedule_prep(napi)) { + vi->rvq->vq_ops->disable_cb(vi->rvq); + __netif_rx_schedule(vi->dev, napi); goto again; + } } return received; @@ -282,6 +285,7 @@ again: * means some were used in the meantime. */ if (unlikely(!...

...============================================== --- kvm.orig/drivers/net/virtio_net.c +++ kvm/drivers/net/virtio_net.c @@ -203,8 +203,11 @@ again: if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->enable_cb(vi->rvq)) - && netif_rx_reschedule(vi->dev, napi)) + && napi_schedule_prep(napi)) { + vi->rvq->vq_ops->disable_cb(vi->rvq); + __netif_rx_schedule(vi->dev, napi); goto again; + } } return received; @@ -282,6 +285,7 @@ again: * means some were used in the meantime. */ if (unlikely(!...

Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU: 2 Not tainted Process swapper (pid: 0, task: 000000000f83e038, ksp: 000000000f877d70) Krnl

Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU: 2 Not tainted Process swapper (pid: 0, task: 000000000f83e038, ksp: 000000000f877d70) Krnl

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c