linux-mips
[Top] [All Lists]

Re: [E1000-devel] [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enabl

To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [E1000-devel] [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Date: Mon, 7 Oct 2013 22:21:49 +0000
Accept-language: en-US
Cc: Tejun Heo <tj@kernel.org>, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>, "VMware, Inc." <pv-drivers@vmware.com>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>, "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>, King <acking@vmware.com>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "Ben Hutchings" <bhutchings@solarflare.com>, Alexander Gordeev <agordeev@redhat.com>, Matt Porter <mporter@kernel.crashing.org>, "iss_storagedev@hp.com" <iss_storagedev@hp.com>, Michael Ellerman <michael@ellerman.id.au>, "linux-driver@qlogic.com" <linux-driver@qlogic.com>, Bjorn Helgaas <bhelgaas@google.com>, "Williams, Dan J" <dan.j.williams@intel.com>, "Mason, Jon" <jon.mason@intel.com>, Molnar <mingo@redhat.com>, Solarflare linux maintainers <linux-net-drivers@solarflare.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Ralf Baechle <ralf@linux-mips.org>, "e1000-devel@lists.sourceforge.net" <e1000-devel@lists.sourceforge.net>, Martin Schwidefsky <schwidefsky@de.ibm.com>, "linux390@de.ibm.com" <linux390@de.ibm.com>, "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
In-reply-to: <1381176656.645.171.camel@pasglop>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <cover.1380703262.git.agordeev@redhat.com> <1380840585.3419.50.camel@bwh-desktop.uk.level5networks.com> <20131004082920.GA4536@dhcp-26-207.brq.redhat.com> <1380922156.3214.49.camel@bwh-desktop.uk.level5networks.com> <20131005142054.GA11270@dhcp-26-207.brq.redhat.com> <1381009586.645.141.camel@pasglop> <20131006060243.GB28142@dhcp-26-207.brq.redhat.com> <1381040386.645.143.camel@pasglop> <20131006071027.GA29143@dhcp-26-207.brq.redhat.com> <20131007180111.GC2481@htj.dyndns.org> <1381176656.645.171.camel@pasglop>
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AQHOwIuZjLWjOrsKJ0GTI3oFcZBHxpnkq+YAgADZ6QCAARqngIAAfHoAgACKqgCAAATCAIAADi0AgAJIIYCAACRBAIAAJJAA
Thread-topic: [E1000-devel] [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Tue, 2013-10-08 at 07:10 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote:
> > I don't think the same race condition would happen with the loop.  The
> > problem case is where multiple msi(x) allocation fails completely
> > because the global limit went down before inquiry and allocation.  In
> > the loop based interface, it'd retry with the lower number.
> > 
> > As long as the number of drivers which need this sort of adaptive
> > allocation isn't too high and the common cases can be made simple, I
> > don't think the "complex" part of interface is all that important.
> > Maybe we can have reserve / cancel type interface or just keep the
> > loop with more explicit function names (ie. try_enable or something
> > like that).
> 
> We want to be able to request an MSI-X at runtime anyway ... if I want
> to dynamically add a queue to my network interface, I want it to be able
> to pop a new arbitrary MSI-X.

If you want to dynamically allocate another queue, you'd either need to
have them all pre-allocated at alloc_etherdev_mqs(), or add a new API to
netdev that allows adding new queues on the fly.

How things are done today, the Tx queues are all tacked onto the end of
the netdev struct.  That would have to change to probably a linked list
of queues that could be grown or shrunk on the fly.
netif_alloc_netdev_queues() would need to change the kzalloc() to a list
allocation.

Cheers,
-PJ
<Prev in Thread] Current Thread [Next in Thread>