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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d68d24ca-a209-01c5-adb6-adaf9a340d84@solarflare.com>
Date:   Wed, 27 Jun 2018 17:34:01 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC:     <linux-net-drivers@...arflare.com>,
        Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>
Subject: 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 <ecree@...arflare.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.