Date: Thu, 22 Feb 2007 03:18:58 -0800 (PST)
Message-Id: <20070222.031858.39163926.davem@davemloft.net>
To: benh@kernel.crashing.org
Cc: shemminger@osdl.org, netdev@vger.kernel.org, ebs@ebshome.net,
       linux-kernel@vger.kernel.org
Subject: Re: [RFC] split NAPI from network device.
From: David Miller <davem@davemloft.net>
In-Reply-To: <1172100271.6792.7.camel@localhost.localdomain>
References: <20061213154635.1f284bf6@dxpl.pdx.osdl.net>
	<20070220.213125.74747066.davem@davemloft.net>
	<1172100271.6792.7.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1976
Lines: 45

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 22 Feb 2007 10:24:31 +1100

> The device has a single interrupt though that interrupt at least can
> tell you which queues need servicing. It can't mask the interrupt per
> queue though, which is the main issue.

Right, which effectively turns it into a single interrupt
for multiple queues as far as NAPI is concerned.

> So while I think this scheme would work (the driver, ibm_emac, currently
> uses a fake net_device and that sort-of works, budget is set a CONFIG_*
> time though, I'm sure that can/needs to be improved), I've been
> wondering all along if I could do something smarter by doing some
> interrupt soft-disabling instead, though I have to get my head around
> properly kicking softirqs from task context (if I need to re-trigger
> from a enable_*() call occuring at task context).

If you cannot make use of it sanely in your driver, it's hard to
justify this patch just in the cleanup sense since it breaks
NAPI interfaces and makes driver maintainence harder than it would
need to be.

Whereas if it makes a straightforward implementation in drivers
like ibm_emac possible, this tends to tip things over the edge
such that we can justify the maintainence hassles to some extent.

I think the intention with these changes, is that you would
have a napi struct per-queue.  It would be embedded in some
private per-queue software state struct, and from which you
could also get to the device.  So you'd do the "container_of()"
bit a little bit differently at the beginning of your ->poll()
method.

This way you don't need the dummy netdevices.

Anyways, please let us know what you come up with once you get
a chance to investigate this.

Thanks!
-
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/