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. -- error compiling committee.c: too many arguments to function _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
