On Sun, 2006-06-11 at 17:13 -0700, Neil Horman wrote: > Any further thoughts on this guys? I still think my last solution > solves all of > the netpoll problems, and isn't going to have any noticable impact on > performance. > I haven't had time to evaluate performance on your patch (sorry!), but after thinking about it, I agree that it should not have any noticeable impact. OTOH, performance tuning is a funny thing, and things you think won't cause problems often do.
Anyway, I'm still not quite ready to ACK this because it's just not future-proof. Eventually, we will need to support multiple RX queues, and this solution will not work in that situation. A simpler short-term solution is just to schedule our NAPI polling on the "real" netdev instead of our polling netdev. This is a trivial change and works correctly with a single queue. But, like your patch, it isn't future-proof. So, I'm still thinking and pondering on this one. If we get a patch in to fix the recursive loop in netpoll, my original patch will work, right? Or is there still another issue? -Mitch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
