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

[Edward Cree <ecree@solarflare.com>]

On 27/06/18 15:36, Willem de Bruijn wrote:
> On Tue, Jun 26, 2018 at 8:19 PM Edward Cree <ecree@solarflare.com> wrote:
>> __netif_receive_skb_taps() does a depressingly large amount of per-packet
>>  work that can't easily be listified, because the another_round looping
>>  makes it nontrivial to slice up into smaller functions.
>> Fortunately, most of that work disappears in the fast path:
>>  * Hardware devices generally don't have an rx_handler
>>  * Unless you're tcpdumping or something, there is usually only one ptype
>>  * VLAN processing comes before the protocol ptype lookup, so doesn't force
>>    a pt_prev deliver
>>  so normally, __netif_receive_skb_taps() will run straight through and return
>>  the one ptype found in ptype_base[hash of skb->protocol].
>>
>> Signed-off-by: Edward Cree <ecree@solarflare.com>
>> ---
>> -static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
>> +static int __netif_receive_skb_taps(struct sk_buff *skb, bool pfmemalloc,
>> +                                   struct packet_type **pt_prev)
> A lot of code churn can be avoided by keeping local variable pt_prev and
> calling this ppt_prev or so, then assigning just before returning on success.
Good idea, I'll try that.

> 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?