Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753372AbbBMSTa (ORCPT ); Fri, 13 Feb 2015 13:19:30 -0500 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:59077 "EHLO e06smtp10.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753254AbbBMST2 (ORCPT ); Fri, 13 Feb 2015 13:19:28 -0500 Date: Fri, 13 Feb 2015 19:19:18 +0100 From: Cornelia Huck To: Rusty Russell Cc: "Michael S. Tsirkin" , Jason Wang , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, pagupta@redhat.com, Pawel Moll Subject: Re: [PATCH RFC v5 net-next 4/6] virtio-net: add basic interrupt coalescing support Message-ID: <20150213191918.0caf0d9a.cornelia.huck@de.ibm.com> In-Reply-To: <874mqqbk12.fsf@rustcorp.com.au> References: <1423471165-34243-1-git-send-email-jasowang@redhat.com> <1423471165-34243-5-git-send-email-jasowang@redhat.com> <87386ey2iy.fsf@rustcorp.com.au> <20150210104019.GD9505@redhat.com> <874mqqbk12.fsf@rustcorp.com.au> Organization: IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz =?UTF-8?B?R2VzY2jDpGZ0c2bDvGhydW5nOg==?= Dirk Wittkopp Sitz der Gesellschaft: =?UTF-8?B?QsO2Ymxpbmdlbg==?= Registergericht: Amtsgericht Stuttgart, HRB 243294 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15021318-0041-0000-0000-0000033FABE7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2765 Lines: 58 On Fri, 13 Feb 2015 13:22:09 +1030 Rusty Russell wrote: > "Michael S. Tsirkin" writes: > > On Tue, Feb 10, 2015 at 12:02:37PM +1030, Rusty Russell wrote: > >> Jason Wang writes: > >> > This patch enables the interrupt coalescing setting through ethtool. > >> > >> The problem is that there's nothing network specific about interrupt > >> coalescing. I can see other devices wanting exactly the same thing, > >> which means we'd deprecate this in the next virtio standard. > >> > >> I think the right answer is to extend like we did with > >> vring_used_event(), eg: > >> > >> 1) Add a new feature VIRTIO_F_RING_COALESCE. > >> 2) Add another a 32-bit field after vring_used_event(), eg: > >> #define vring_used_delay(vr) (*(u32 *)((vr)->avail->ring[(vr)->num + 2])) > >> > >> This loses the ability to coalesce by number of frames, but we can still > >> do number of sg entries, as we do now with used_event, and we could > >> change virtqueue_enable_cb_delayed() to take a precise number if we > >> wanted. > > > > But do we expect delay to be update dynamically? > > If not, why not stick it in config space? > > Hmm, we could update it dynamically (and will, in the case of ethtool). > But it won't be common, so we could append a field to > virtio_pci_common_cfg for PCI. > > I think MMIO and CCW would be easy to extend too, but CC'd to check. If this is a simple extension of the config space, it should just work for ccw (the Linux guest driver currently uses 0x100 as max config space size, which I grabbed from pci at the time I wrote it). But looking at this virtio_pci_common_cfg stuff, it seems to contain a lot of things that are handled via ccws on virtio-ccw (like number of queues or device status). Having an extra ccw just for changing this delay value seems like overkill. On the basic topic of interrupt coalescing: With adapter interrupts, virtio-ccw already has some kind of coalescing: The summary indicator is set just once and an interrupt is made pending, then individual queue indicators are switched on and no further interrupt is generated if the summary indicator has not been cleared by the guest yet. I'm not sure how it would be different if an individual queue indicator is switched on later. Chances are that the guest code processing the indicators has not even yet processed to that individual indicator, so it wouldn't matter if it was set delayed. It is probably something that has to be tried out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/