On Wed, 2008-05-14 at 11:59 +0300, Avi Kivity wrote: > Rusty Russell wrote: > >> Sorry to barge in late, but IMO the timer should be on the host, which > >> is cheaper than on the guest (well, a 100ms timer is likely zero cost, > >> but I still don't like it). > >> > >> the host should fire a tx completion interrupt whenever the completion > >> queue has "enough" entries, where we can define "enough" now as the > >> halfway mark or a timer expiry, whichever comes earlier. > >> > >> We can later improve "enough" to be "just enough so the timer never > >> triggers" and adjust it dynamically. It probably doesn't matter for > >> Linux, but I don't want to punish guests that can do true async > >> networking and depend on timely completion notification. > >> > > > > This implies that we should not be supressing notifications in the guest at > > all (unless we're sure there are more packets to come, which currently we > > never are: that needs new net infrastructure). > > > > We don't have to be sure, just reasonably confident. If we see a stream > of packets, we open the window, but set a timer in case we're wrong. > The expectation is that the timer will only fire when tx rate drops (or > tx stops completely). > > > But that means we'd get a notification on every xmit at the moment. > > Benchmarks anyone? > > > > Notification on every xmit will surely kill performance. I'm trying to > get batching to work but also good latency when the link is not saturated. I think Rusty is speaking from the POV of the guest driver - i.e. that virtio_net should never disable notifications on the xmit queue using disable_cb()? Sounds like you think agree, but that the host side should throttle the rate of xmit notifications? Cheers, Mark. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
