Thread (17 messages) 17 messages, 2 authors, 2021-01-05

Re: [RFC PATCH v3 00/12] Generic zcopy_* functions

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2021-01-05 04:23:53

On Mon, Jan 4, 2021 at 11:17 PM Jonathan Lemon [off-list ref] wrote:
On Mon, Jan 04, 2021 at 12:39:35PM -0500, Willem de Bruijn wrote:
quoted
On Wed, Dec 30, 2020 at 2:12 PM Jonathan Lemon [off-list ref] wrote:
quoted
From: Jonathan Lemon <redacted>

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help