On Tue, 2014-03-11 at 01:43 -0700, Eric W. Biederman wrote: > It does seem desirable that netpoll should not drain the rx queues. > Unfortunately that is not how netpoll is built. By my quick count > there are 132 drivers in the kernel that support netpoll. > > Several of them such as the e1000e driver already call dev_kfree_skb_any > or dev_kfree_skb_irq in their rx paths. What I am implementing seems to > be the pattern that the better drivers follow today. > > Furthermore netpoll by it's design depends on the ability to receive > packets in netpoll_poll_dev. It is a capability I don't think we have > ever used in the mainline kernel but it is a capability that is there > deliberately. Which means if we want netpoll to not mess with the rx > path we need to change netpoll. > > > If we are willing to change the definition of netpoll this is fixable. > > The big enabler is the fact that calling the napi poll function with a > budget of 0 means don't perform any rx work. > > Which leads to the following set of changes to netpoll if we are brave. Well, it cannot be worse than current situation, right ? I never understood and never enabled CONFIG_NETPOLL_TRAP on any of my builds, I can tell you. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html