On 7/2/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > Fake netdevs are needed for doing the multiple Rx queues in NAPI
mode.
> > We are thinking to solve in 2 ways. Having netdev pointer in ring
> > structure or having an array of netdev pointers in ixgbe_adatper
struct
> > which would be visible to all rings.
>
> Wait until Davem & I separate NAPI from network device.
> The patch is close to ready for 2.6.24 when this driver will need to
show up.
>
> Since I know Intel will be forced to backport this to older distro's.
You
> would be best to have a single receive queue version when you have to
make
> it work on the older code.
So far all our testing indicates we need multiple Rx queues to have
better CPU utilization number at 10Gig line rate. So I am thinking
adding the non-NAPI support to the driver (like other 10Gig drivers) and
restrict to single rx queue in case of NAPI. I already have the non-NAPI
version coded up and went through internal testing. I will add this in
the next submission. We will add the multiple Rx queues support in NAPI
mode once when "separate NAPI from network device" is done. Does this
sound ok?
>
> You only need to store the name for when you are doing request_irq, so
> it can just be a stack temporary.
>
request_irq expects allocated memory not just stack temporary. I glanced
the kernel source.. There are precedents to the way we did.
linux-2.6/source/drivers/usb/core/hcd.c
1594 /* enable irqs just before we start the controller */
1595 if (hcd->driver->irq) {
1596 snprintf(hcd->irq_descr, sizeof(hcd->irq_descr),
"%s:usb%d",
1597 hcd->driver->description,
hcd->self.busnum);
1598 if ((retval = request_irq(irqnum, &usb_hcd_irq,
irqflags,
1599 hcd->irq_descr, hcd)) != 0) {
1600 dev_err(hcd->self.controller,
1601 "request interrupt %d
failed\n", irqnum);
1602 goto err_request_irq;
1603 }
> Stephen Hemminger <[EMAIL PROTECTED]>
I appreciate the feedback.
Thanks,
Ayyappa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
