netdev - Re: [RFC PATCH v3 00/12] Generic zcopy

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-Jb-tkxYPHrnAk3x641RY6tnrGOJB0UkrBWrXmvuRiM9w@mail.gmail.com>
Date:   Mon, 4 Jan 2021 12:39:35 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Jonathan Lemon <jonathan.lemon@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        David Ahern <dsahern@...il.com>,
        Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH v3 00/12] Generic zcopy_* functions

On Wed, Dec 30, 2020 at 2:12 PM Jonathan Lemon <jonathan.lemon@...il.com> wrote:
>
> From: Jonathan Lemon <bsd@...com>
>
> This is set of cleanup patches for zerocopy which are intended
> to allow a introduction of a different zerocopy implementation.
>
> The top level API will use the skb_zcopy_*() functions, while
> the current TCP specific zerocopy ends up using msg_zerocopy_*()
> calls.
>
> There should be no functional changes from these patches.
>
> v2->v3:
>  Rename zc_flags to 'flags'.  Use SKBFL_xxx naming, similar
>  to the SKBTX_xx naming.  Leave zerocopy_success naming alone.
>  Reorder patches.
>
> v1->v2:
>  Break changes to skb_zcopy_put into 3 patches, in order to
>  make it easier to follow the changes.  Add Willem's suggestion
>  about renaming sock_zerocopy_

Overall, this latest version looks fine to me.

The big question is how this fits in with the broader rx direct
placement feature. But it makes sense to me to checkpoint as is at
this point.

One small comment: skb_zcopy_* is a logical prefix for functions that
act on sk_buffs, Such as skb_zcopy_set, which associates a uarg with
an skb. Less for functions that operate directly on the uarg, and do
not even take an skb as argument: skb_zcopy_get and skb_zcopy_put.
Perhaps net_zcopy_get/net_zcopy_put?