search for: sk_busy_loop

...be to actually poll >>> the underlying device. This should be reasonably >>> straight-forward with macvtap (especially in the >>> passthrough mode). >>> >>> >> Yes, it is. I have some patches to do this by replacing >> skb_queue_empty() with sk_busy_loop() but for tap. > We probably don't want to do this unconditionally, though. > >> Tests does not show >> any improvement but some regression. > Did you add code to call sk_mark_napi_id on tap then? > sk_busy_loop won't do anything useful without. Yes I did. Probably...

...be to actually poll >>> the underlying device. This should be reasonably >>> straight-forward with macvtap (especially in the >>> passthrough mode). >>> >>> >> Yes, it is. I have some patches to do this by replacing >> skb_queue_empty() with sk_busy_loop() but for tap. > We probably don't want to do this unconditionally, though. > >> Tests does not show >> any improvement but some regression. > Did you add code to call sk_mark_napi_id on tap then? > sk_busy_loop won't do anything useful without. Yes I did. Probably...

...wang at redhat.com> > One further enhancement would be to actually poll > the underlying device. This should be reasonably > straight-forward with macvtap (especially in the > passthrough mode). > > Yes, it is. I have some patches to do this by replacing skb_queue_empty() with sk_busy_loop() but for tap. Tests does not show any improvement but some regression. Maybe it's better to test macvtap.

...wang at redhat.com> > One further enhancement would be to actually poll > the underlying device. This should be reasonably > straight-forward with macvtap (especially in the > passthrough mode). > > Yes, it is. I have some patches to do this by replacing skb_queue_empty() with sk_busy_loop() but for tap. Tests does not show any improvement but some regression. Maybe it's better to test macvtap.

...enhancement would be to actually poll > > the underlying device. This should be reasonably > > straight-forward with macvtap (especially in the > > passthrough mode). > > > > > > Yes, it is. I have some patches to do this by replacing > skb_queue_empty() with sk_busy_loop() but for tap. We probably don't want to do this unconditionally, though. > Tests does not show > any improvement but some regression. Did you add code to call sk_mark_napi_id on tap then? sk_busy_loop won't do anything useful without. > Maybe it's better to test macvtap....

...gt; the underlying device. This should be reasonably > >>> straight-forward with macvtap (especially in the > >>> passthrough mode). > >>> > >>> > >> Yes, it is. I have some patches to do this by replacing > >> skb_queue_empty() with sk_busy_loop() but for tap. > > We probably don't want to do this unconditionally, though. > > > >> Tests does not show > >> any improvement but some regression. > > Did you add code to call sk_mark_napi_id on tap then? > > sk_busy_loop won't do anything useful...

...int, S_IRUGO|S_IWUSR); > +MODULE_PARM_DESC(poll_stop_idle, "Stop continuous polling of virtqueue after this many jiffies of no work."); > > enum { > VHOST_MEMORY_MAX_NREGIONS = 64, So how does one know whether the heuristic works? We need some kind of counter here. E.g. sk_busy_loop uses NET_ADD_STATS_BH(sock_net(sk), LINUX_MIB_BUSYPOLLRXPACKETS, rc); > @@ -58,27 +66,28 @@ static int vhost_poll_wakeup(wait_queue_t *wait, unsigned mode, int sync, > return 0; > } > > -void vhost_work_init(stru...

From: Razya Ladelsky <razya at il.ibm.com> Date: Thu, 31 Jul 2014 09:47:20 +0300 Subject: [PATCH] vhost: Add polling mode When vhost is waiting for buffers from the guest driver (e.g., more packets to send in vhost-net's transmit queue), it normally goes to sleep and waits for the guest to "kick" it. This kick involves a PIO in the guest, and therefore an exit (and possibly

From: Razya Ladelsky <razya at il.ibm.com> Date: Thu, 31 Jul 2014 09:47:20 +0300 Subject: [PATCH] vhost: Add polling mode When vhost is waiting for buffers from the guest driver (e.g., more packets to send in vhost-net's transmit queue), it normally goes to sleep and waits for the guest to "kick" it. This kick involves a PIO in the guest, and therefore an exit (and possibly