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: Mon, 26 Nov 2018 13:19:23 -0500	[thread overview]
Message-ID: <CAF=yD-KG+wyHkX40FXPXNiNEHeKjOd5hPSDFuh-z0pUAnLehLg@mail.gmail.com> (raw)
In-Reply-To: <ae1b8e52272b14a49ff4225e647c86c0aab57980.camel@redhat.com>

On Mon, Nov 26, 2018 at 1:04 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Mon, 2018-11-26 at 12:59 -0500, Willem de Bruijn wrote:
> > The callers of this function do flush the queue of the other skbs on
> > error, but only after the call to sock_zerocopy_put_abort.
> >
> > sock_zerocopy_put_abort depends on total rollback to revert the
> > sk_zckey increment and suppress the completion notification (which
> > must not happen on return with error).
> >
> > I don't immediately have a fix. Need to think about this some more..
>
> [still out of sheer ignorance] How about tacking a refcnt for the whole
> ip_append_data() scope, like in the tcp case? that will add an atomic
> op per loop (likely, hitting the cache) but will remove some code hunk
> in sock_zerocopy_put_abort() and sock_zerocopy_alloc().

The atomic op pair is indeed what I was trying to avoid. But I also need
to solve the problem that the final decrement will happen from the freeing
of the other skbs in __ip_flush_pending_frames, and will not suppress
the notification.

Freeing the entire queue inside __ip_append_data, effectively making it
a true noop on error is one approach. But that is invasive, also to non
zerocopy codepaths, so I would rather avoid that.

Perhaps I need to handle the abort logic in udp_sendmsg directly,
after both __ip_append_data and __ip_flush_pending_frames.

  reply	other threads:[~2018-11-27  5:14 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 [this message]
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
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-KG+wyHkX40FXPXNiNEHeKjOd5hPSDFuh-z0pUAnLehLg@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.