On 27/06/18 17:00, Willem de Bruijn wrote: > On Wed, Jun 27, 2018 at 10:49 AM Edward Cree <ec...@solarflare.com> wrote: >> On 27/06/18 15:36, Willem de Bruijn wrote: >>> Also, this function does more than just process network taps. >> This is true, but naming things is hard, and I couldn't think of either a >> better new name for this function or a name that could fit in between >> __netif_receive_skb() and __netif_receive_skb_core() for the new function >> in my patch named __netif_receive_skb_core(). Any suggestions? > ____netif_receive_skb_core? Not that four underscores is particularly > readable. Perhaps __netif_receive_skb_core_inner. It's indeed tricky (and > not the most important, I didn't mean to bikeshed). I've gone with __netif_receive_skb_one_core() (by contrast to ..._list_core()) for the outer function. And I don't mind when people shed bikes :)
> Come to think of it, from your fast path assumptions, we could perhaps wrap > ptype_all and rx_handler logic in a static_branch similar to tc and netfilter > (and sk_memalloc_socks). Remaining branches like skip_classify, pfmemalloc > and deliver_exact can also not be reached if all these are off, so this entire > section can be skipped. Then it could become __netif_receive_skb_slow, > taken only on the static branch or for vlan packets. I do not suggest it as > part of this patchset. it would be a pretty complex change on its own. That is an interesting idea, but agreed that it'd be quite complex.
