All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Network Development <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next v2 1/2] udp: msg_zerocopy
Date: Thu, 29 Nov 2018 11:17:57 -0500	[thread overview]
Message-ID: <CAF=yD-KZK7R+CFg9CVR6bx3E7Qgk9rEUP0FVt89C74rRnSQahg@mail.gmail.com> (raw)
In-Reply-To: <4cd6006ed79a2690ee89f46c699553064f2500f4.camel@redhat.com>

On Thu, Nov 29, 2018 at 3:27 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hi,
>
> Thank you for the update!
>
> On Wed, 2018-11-28 at 18:50 -0500, Willem de Bruijn wrote:
> > I did revert to the basic implementation using an extra ref
> > for the function call, similar to TCP, as you suggested.
> >
> > On top of that as a separate optimization patch I have a
> > variant that uses refcnt zero by replacing refcount_inc with
> > refcount_set(.., refcount_read(..) + 1). Not very pretty.
>
> If the skb/uarg is not shared (no other threads can touch the refcnt)
> before ip*_append_data() completes, how about something like the
> following (incremental diff on top of patch 1/2, untested, uncompiled,
> just to give the idea):
>
> The basic idea is using the same schema currently used for wmem
> accounting: do the book-keeping inside the loop and set the atomic
> reference counter only once at the end of the loop.
>
> WDYT?

Thanks for the suggestion. I think that a variant of this might be the
best option indeed.

The common case that we care about (ip_make_skb without
fragmentation) only builds one skb, so we won't necessarily
amortize many atomic ops. I also really would like to avoid the
atomic op and branch in the non-error return path.

But with uarg_refs we can indeed elide the refcount_inc on the
first skb_zcopy_get and detect at skb_zerocopy_put_abort if the
extra reference went unused and it has to put the ref itself.

Let me code that up. Thanks!

  reply	other threads:[~2018-11-30  3:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 15:29 [PATCH net-next v2 0/2] udp msg_zerocopy Willem de Bruijn
2018-11-26 15:29 ` [PATCH net-next v2 1/2] udp: msg_zerocopy Willem de Bruijn
2018-11-26 16:32   ` Paolo Abeni
2018-11-26 17:59     ` Willem de Bruijn
2018-11-26 18:04       ` Paolo Abeni
2018-11-26 18:19         ` Willem de Bruijn
2018-11-26 19:49           ` Willem de Bruijn
2018-11-28 23:50             ` Willem de Bruijn
2018-11-29  8:27               ` Paolo Abeni
2018-11-29 16:17                 ` Willem de Bruijn [this message]
2018-11-29  7:31   ` [udp] a4a142d3d7: WARNING:at_lib/refcount.c:#refcount_inc_checked kernel test robot
2018-11-29  7:31     ` kernel test robot
2018-11-26 15:29 ` [PATCH net-next v2 2/2] selftests: extend zerocopy tests to udp Willem de Bruijn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF=yD-KZK7R+CFg9CVR6bx3E7Qgk9rEUP0FVt89C74rRnSQahg@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.