From: Jarek Poplawski <jarkao2@xxxxxxxxx> Date: Wed, 21 Oct 2009 23:39:47 +0200 > I'm not sure I can understand your question. This patch is mainly to > avoid using netif_rx()/netif_rx_ni() pair as a test of proper process > context handling; IMHO there're better tools for this (lockdep, > WARN_ON's). Semantically I think your patch is correct, but I wonder about cost. Something that is a simply per-cpu inline "or" operation is now a function call and potentially mispredicted branch inside of raise_softirq_irqoff(). And netif_rx() is indeed a fast path for tunnels and other users so this does matter. I like having people call things in the correct context the function was built for, and thus we can avoiryd completely useless operations and tests as we can now in netif_rx(). Makaing things general purpose costs something, and it costs too much here for this critical routine, sorry. I was just having a talk with Nick Piggin about these kinds of issues today, too few people care about these ever encrouching tiny pieces of bloat that slow the kernel down gradually over time, and I simply won't stand for it when I notice it :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
