Re: [PATCH 1/2] rps: core implementation

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andi Kleen
Date: Wednesday, November 11, 2009 - 2:43 pm

Tom Herbert <therbert@google.com> writes:


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
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 1/2] rps: core implementation, Tom Herbert, (Tue Nov 10, 11:53 pm)
Re: [PATCH 1/2] rps: core implementation, Eric Dumazet, (Wed Nov 11, 1:20 am)
Re: [PATCH 1/2] rps: core implementation, Tom Herbert, (Wed Nov 11, 9:28 am)
Re: [PATCH 1/2] rps: core implementation, Randy Dunlap, (Wed Nov 11, 9:49 am)
Re: [PATCH 1/2] rps: core implementation, Andi Kleen, (Wed Nov 11, 2:43 pm)
Re: [PATCH 1/2] rps: core implementation, Andi Kleen, (Wed Nov 11, 2:44 pm)
Re: [PATCH 1/2] rps: core implementation, David Miller, (Wed Nov 11, 7:32 pm)
Re: [PATCH 1/2] rps: core implementation, Eric Dumazet, (Thu Nov 12, 1:23 pm)
Re: [PATCH 1/2] rps: core implementation, David Miller, (Mon Nov 16, 4:15 am)
Re: [PATCH 1/2] rps: core implementation, David Miller, (Mon Nov 16, 4:19 am)
Re: [PATCH 1/2] rps: core implementation, Tom Herbert, (Mon Nov 16, 9:43 am)
Re: [PATCH 1/2] rps: core implementation, Tom Herbert, (Mon Nov 16, 10:02 am)
Re: [PATCH 1/2] rps: core implementation, Jarek Poplawski, (Tue Nov 17, 2:32 pm)
Re: [PATCH 1/2] rps: core implementation, David Miller, (Wed Nov 18, 12:21 am)
Re: [PATCH 1/2] rps: core implementation, Andi Kleen, (Thu Nov 19, 3:08 am)
Re: [PATCH 1/2] rps: core implementation, Tom Herbert, (Thu Nov 19, 11:41 pm)
Re: [PATCH 1/2] rps: core implementation, Eric Dumazet, (Thu Nov 19, 11:49 pm)