On Mon, 2009-03-16 at 23:22 +0100, Eric Dumazet wrote:
I read the entire thread up to now, and I still don't really understand
the Changelog, sorry :(
How does that solve the wakeup issue?
Why the magic termination value? Can't we NULL terminate the list
Shouldn't we call it __softirq_delay_queue() if the caller needs to
disabled preemption?
Futhermore, don't we always require the caller to take care of lifetime
issues when we queue something?
Why can't we write:
struct softirq_delay *sdel, *next;
sdel = __get_cpu_var(softirq_delay_head);
__get_cpu_var(softirq_delay_head) = NULL;
while (sdel) {
next = sdel->next;
sdel->func(sdel);
sdel = next;
}
Why does it matter what happens to sdel->next? we've done the callback.
Aah, the crux is in the re-use policy.. that most certainly does deserve
a comment.
How about we make sdel->next point to itself in the init case?
Then we can write:
while (sdel) {
next = sdel->next;
sdel->next = sdel;
sdel->func(sdel);
sdel = next;
}
and have the enqueue bit look like:
int __softirq_delay_queue(struct softirq_delay *sdel)
{
struct softirq_delay **head;
if (sdel->next != sdel)
return 0;
head = &__get_cpu_var(softirq_delay_head);
sdel->next = *head;
*head = sdel;
return 1;
}
Where's the matching barrier?
OK, so the idea is to handle a bunch of packets and instead of waking N
threads for each packet, only wake them once at the end of the batch?
Sounds like a sensible idea..
--
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