From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [RFC] Remove tx_timer from virtio_net Date: Tue, 8 Jan 2008 08:54:09 +1100 Message-ID: <200801080854.09550.rusty@rustcorp.com.au> References: <47828D5D.5080700@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Avi Kivity To: Anthony Liguori Return-path: In-Reply-To: <47828D5D.5080700-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Tuesday 08 January 2008 07:36:45 Anthony Liguori wrote: > Avi and I were talking this afternoon and he suggested that we should > remove the tx_timer from the virtio_net front-end and replace it with a > tx_timer in the backend. > > Since the backend can suppress notifications, this is appealing since it > gives much more flexibility to the backend in determining how to do tx > batching. I've done a quick implementation and performance is pretty good. > > We may need an ABI change, however. When the backend disables > notifications, there is absolutely no way for the frontend to notify > anymore. In the case where the queue fills up, it cannot flush since > the backend has disabled notifications. To work around this, I had to > least notifications enabled and check for the case where the queue fills > up manually. > > I think a possible solution to this would be to differentiate between a > soft and hard notify. We would introduce a VRING_USED_F_NOTIFY_ON_FULL > and a VRING_AVAIL_F_NOTIFY_ON_FULL. > > The NO_NOTIFY variants would indicate that the other end never sends a > notify, whereas NOTIFY_ON_FULL would indicate that the other end never > sends a notify unless the queue fills up. Hi Anthony, I really like this (in proportion to my discomfort with the hrtimers hack, in fact). The good news is that I don't think we need a significant ABI change: I think we should have the vring_get_buf() failure path kick the other end unconditionally. This makes sense: the NO_INTERRUPT flag is really a "you don't need to interrupt me" hint; you're allowed to interrupt even if it's set. So it should be at worst harmless. It should work in the inter-guest case, for example. Rather than apply this, I will just drop the hrtimer patches, and do a separate "kick on queue full" patch. Thanks! Rusty. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace