Re: [RFC PATCH v2 net-next 06/12] net: core: propagate SKB lists through packet_type lookup

On 27/06/18 17:00, Willem de Bruijn wrote:

On Wed, Jun 27, 2018 at 10:49 AM Edward Cree [off-list ref] wrote:

quoted

On 27/06/18 15:36, Willem de Bruijn wrote:

quoted

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.