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.