All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederik Deweerdt <frederik.deweerdt@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario
Date: Wed, 1 Jun 2022 16:01:07 -0700	[thread overview]
Message-ID: <Ypfvs+VsNHWQKT6H@fractal.lan> (raw)
In-Reply-To: <CA+FuTSeCC=sKJhKEnavLA7qdwbGz=MC1wqFPoJQA04mZBqebow@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

Hi Willem,

On Wed, Jun 01, 2022 at 09:24:32AM -0400, Willem de Bruijn wrote:
> On Tue, May 31, 2022 at 10:48 PM Frederik Deweerdt
> <frederik.deweerdt@gmail.com> wrote:
> >
> > Hi folks,
> >
> > Based on my understanding, retransmissions of zero copied buffers can
> > happen after `close(2)`, the patch below amends the docs to suggest how
> > notifications should be handled in that case.
> 
> Not just retransmissions. The first transmission similarly may be queued.
> 
> >
[...]
> > @@ -144,6 +144,10 @@ the socket. A socket that has an error queued would normally block
> >  other operations until the error is read. Zerocopy notifications have
> >  a zero error code, however, to not block send and recv calls.
> >
> > +For protocols like TCP, where retransmissions can occur after the
> > +application is done with a given connection, applications should signal
> > +the close to the peer via shutdown(2), and keep polling the error queue
> > +until all transmissions have completed.
> 
> A socket must not be closed until all completion notifications have
> been received.
> 
> Calling shutdown is an optional step. It may be sufficient to simply
> delay close.

Thank you for the feedback, that helps!

What do you think of the attached patch?

Frederik

Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1155 bytes --]

commit 3218d973b68bc6d9f88d9e2374f3ada3df5ee7ff
Author: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Date:   Tue May 31 18:23:54 2022 -0700

    [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario
    
    Explicitly mention that applications shouldn't be calling `close(2)` on
    a TCP socket without draining the error queue.

diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst
index 15920db8d35d..9373631d0a82 100644
--- a/Documentation/networking/msg_zerocopy.rst
+++ b/Documentation/networking/msg_zerocopy.rst
@@ -144,6 +144,11 @@ the socket. A socket that has an error queued would normally block
 other operations until the error is read. Zerocopy notifications have
 a zero error code, however, to not block send and recv calls.
 
+For protocols like TCP, transmissions can occur after the application
+has called close(2). In cases where it's undesirable to delay calling
+close(2) until all notifications have been processed, the application
+can use shutdown(2), and keep polling the error queue until all
+transmissions have completed.
 
 Notification Batching
 ~~~~~~~~~~~~~~~~~~~~~

  reply	other threads:[~2022-06-01 23:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01  2:47 [PATCH] [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario Frederik Deweerdt
2022-06-01 13:24 ` Willem de Bruijn
2022-06-01 23:01   ` Frederik Deweerdt [this message]
2022-06-02  0:29     ` Willem de Bruijn
2022-06-03 13:09     ` David Laight
2022-06-03 13:30       ` Willem de Bruijn
2022-06-06  7:58         ` David Laight

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=Ypfvs+VsNHWQKT6H@fractal.lan \
    --to=frederik.deweerdt@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=willemdebruijn.kernel@gmail.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.