diff options
author | Willem de Bruijn <willemb@google.com> | 2018-11-30 15:32:40 -0500 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-12-03 15:58:32 -0800 |
commit | 52900d22288e7d45846037e1db277c665bbc40db (patch) | |
tree | 8e69a5639d94cd4774bfc4645f5f0397abfb8cb8 /lib/atomic64_test.c | |
parent | b5947e5d1e710c35ea281247bd27e6975250285c (diff) | |
download | linux-stable-52900d22288e7d45846037e1db277c665bbc40db.tar.gz linux-stable-52900d22288e7d45846037e1db277c665bbc40db.tar.bz2 linux-stable-52900d22288e7d45846037e1db277c665bbc40db.zip |
udp: elide zerocopy operation in hot path
With MSG_ZEROCOPY, each skb holds a reference to a struct ubuf_info.
Release of its last reference triggers a completion notification.
The TCP stack in tcp_sendmsg_locked holds an extra ref independent of
the skbs, because it can build, send and free skbs within its loop,
possibly reaching refcount zero and freeing the ubuf_info too soon.
The UDP stack currently also takes this extra ref, but does not need
it as all skbs are sent after return from __ip(6)_append_data.
Avoid the extra refcount_inc and refcount_dec_and_test, and generally
the sock_zerocopy_put in the common path, by passing the initial
reference to the first skb.
This approach is taken instead of initializing the refcount to 0, as
that would generate error "refcount_t: increment on 0" on the
next skb_zcopy_set.
Changes
v3 -> v4
- Move skb_zcopy_set below the only kfree_skb that might cause
a premature uarg destroy before skb_zerocopy_put_abort
- Move the entire skb_shinfo assignment block, to keep that
cacheline access in one place
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'lib/atomic64_test.c')
0 files changed, 0 insertions, 0 deletions