On Mon, Jan 4, 2021 at 11:17 PM Jonathan Lemon <jonathan.le...@gmail.com> wrote: > > On Mon, Jan 04, 2021 at 12:39:35PM -0500, Willem de Bruijn wrote: > > On Wed, Dec 30, 2020 at 2:12 PM Jonathan Lemon <jonathan.le...@gmail.com> > > wrote: > > > > > > From: Jonathan Lemon <b...@fb.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? > > Or even just zcopy_get / zcopy_put ?
Zerocopy is such an overloaded term, that I'd keep some prefix, at least.
