This really needs the text from 0/2 here as git changelog, otherwise
you make David's life hard if he wants to merge this.
Why is this void * here? This should be a real type.
This has a 4 byte hole on 64bit. Better move it somewhere else
where that isn't the case.
Also make sure you you don't destroy these cache line optimizations.
Similarly here.
Can this really happen? Better might be to move this out of the fast path.
Why only [3] ? Is this future proof?
How do you get around the standard deadlocks with IPI called from
irq disabled section?
And why are the interrupts are disabled here anyways?
When you just disabled the irqs you obviously don't need a irqsave
in the next line.
This will actually not turn on interrupts again because you only
saved them after disabling them.
Same
It's a standard pet peeve of me, but it's quite unlikely you'll
get any useful entropy at this time of kernel startup.
Normally it's always the same.
It seems weird to do user parsing while holding that lock.
Better first set up and allocate and then finally initialize global state.
Especially since the device is alive. So what happens to interrupts
coming in in parallel? That seems racy.
+
+ queue = &per_cpu(softnet_data, cpu);
+ spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
+
+ __get_cpu_var(netdev_rx_stat).total++;
+ if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
It seems weird to do the local counter increase after grabbing
the global lock. Also does someone count on the real receiver anyways?
That might be better, right now the count would be a bit
misleading.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html