On 09/30/2013 12:56 PM, Aaro Koskinen wrote:
Hi,
On Mon, Sep 30, 2013 at 12:41:59PM -0700, David Daney wrote:
On 09/30/2013 12:35 PM, Aaro Koskinen wrote:
No, the original logic was already broken. The code assumed that the
NAPI scheduled by the driver init gets executed always on CPU 0. The
IRQ got enabled just because we are lucky.
No. The default affinity for all irqs is CPU0 for just this reason.
So there was no luck involved.
According the Kconfig, this driver can be compiled as a module:
config OCTEON_ETHERNET
tristate "Cavium Networks Octeon Ethernet support"
[...]
To compile this driver as a module, choose M here. The module
will be called octeon-ethernet.
What guarantees that CPU0 is around (or the smp_affinity is at its
default value) by the time user executes modprobe?
Nothing enforced by the kernel. Just don't take CPU0 off-line and you
should be good to go.
There is a lot of room for improvement in the driver.
Really this whole thing of starting NAPI on multiple CPUs for the same
input queue is not good. It leads to loss of packet ordering when
forwarding.
What we really want is to have one POW group (input queue) per CPU and
only run one CPU per group. If we did that, we wouldn't have all these
affinity issues.
David Daney
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
