On Wed, Feb 2, 2022 at 4:28 AM Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > Dave suggested a while ago (eleven years by now) "Let's make netif_rx() > work in all contexts and get rid of netif_rx_ni()". Eric agreed and > pointed out that modern devices should use netif_receive_skb() to avoid > the overhead. > In the meantime someone added another variant, netif_rx_any_context(), > which behaves as suggested. > > netif_rx() must be invoked with disabled bottom halves to ensure that > pending softirqs, which were raised within the function, are handled. > netif_rx_ni() can be invoked only from process context (bottom halves > must be enabled) because the function handles pending softirqs without > checking if bottom halves were disabled or not. > netif_rx_any_context() invokes on the former functions by checking > in_interrupts(). > > netif_rx() could be taught to handle both cases (disabled and enabled > bottom halves) by simply disabling bottom halves while invoking > netif_rx_internal(). The local_bh_enable() invocation will then invoke > pending softirqs only if the BH-disable counter drops to zero. > > Add a local_bh_disable() section in netif_rx() to ensure softirqs are > handled if needed. Make netif_rx_ni() and netif_rx_any_context() invoke > netif_rx() so they can be removed once they are no more users left. > > Link: https://lkml.kernel.org/r/20100415.020246.218622820.davem@xxxxxxxxxxxxx > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> Maybe worth mentioning this commit will show a negative impact, for network traffic over loopback interface. My measure of the cost of local_bh_disable()/local_bh_enable() is ~6 nsec on one of my lab x86 hosts. Perhaps we could have a generic netif_rx(), and a __netif_rx() for the virtual drivers (lo and maybe tunnels). void __netif_rx(struct sk_buff *skb); static inline int netif_rx(struct sk_buff *skb) { int res; local_bh_disable(); res = __netif_rx(skb); local_bh_enable(); return res; }
