Several devices have multiple independant RX queues per net
device, and some have a single interrupt doorbell for several
queues.
In either case, it's easier to support layouts like that if the
structure representing the poll is independant from the net
device itself.
The signature of the ->poll() call back goes from:
int foo_poll(struct net_device *dev, int *budget)
to
int foo_poll(struct napi_struct *napi, int budget)
The caller is returned the number of RX packets processed (or
the number of "NAPI credits" consumed if you want to get
abstract). The callee no longer messes around bumping
dev->quota, *budget, etc. because that is all handled in the
caller upon return.
The napi_struct is to be embedded in the device driver private data
structures.
Furthermore, it is the driver's responsibility to disable all NAPI
instances in it's ->stop() device close handler. Since the
napi_struct is privatized into the driver's private data structures,
only the driver knows how to get at all of the napi_struct instances
it may have per-device.
With lots of help and suggestions from Rusty Russell, Roland Dreier,
Michael Chan, Jeff Garzik, and Jamal Hadi Salim.
Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.
[ Ported to current tree and all drivers converted. Integrated
Stephen's follow-on kerneldoc additions, and restored poll_list
handling to the old style to fix mutual exclusion issues. -DaveM ]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The way the hardware and firmware work is that there is one shared RX
queue and IRQ for a number of different network interfaces. Due to this,
we would like to process received packets for every interface in the same
NAPI poll handler, so we need a pseudo-device to schedule polling on.
What the driver currently does is that it always schedules polling for
the first network interface in the list, and processes packets for every
interface in the poll handler for that first interface -- however, this
scheme breaks down if the first network interface happens to not be up,
since netif_rx_schedule_prep() checks netif_running().
sky2 apparently has the same issue, and Stephen Hemminger suggested a
way to work around this: create a variant of netif_rx_schedule_prep()
that does not check netif_running(). I implemented this locally and
called it netif_rx_schedule_prep_notup(), and it seems to work well,
but it's something that probably not everyone would be happy with.
The ixp2000 is an ARM CPU with a high-speed network interface in the
CPU itself (full duplex 4Gb/s or 10Gb/s depending on the IXP model.)
The CPU package also contains 8 or 16 (again depending on the IXP
model) 'microengines', which are somewhat primitive but very fast
and efficient processor cores which can be used to offload various
things from the main CPU.
This driver makes the high-speed network interface in the CPU visible
and usable as a regular linux network device. Currently, it only
supports the Radisys ENP2611 IXP board, but adding support for other
board types should be fairly easy.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Stephen Hemminger
Lennert Buytenhek