All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jens Axboe <axboe@kernel.dk>,
	io-uring@vger.kernel.org, netdev@vger.kernel.org,
	edumazet@google.com
Subject: Re: [PATCHSET 0/4] Add support for no-lock sockets
Date: Tue, 12 Apr 2022 17:40:20 -0700	[thread overview]
Message-ID: <e7631a6f-b614-da4c-4f47-571a7b0149fc@gmail.com> (raw)
In-Reply-To: <20220412202613.234896-1-axboe@kernel.dk>


On 4/12/22 13:26, Jens Axboe wrote:
> Hi,
>
> If we accept a connection directly, eg without installing a file
> descriptor for it, or if we use IORING_OP_SOCKET in direct mode, then
> we have a socket for recv/send that we can fully serialize access to.
>
> With that in mind, we can feasibly skip locking on the socket for TCP
> in that case. Some of the testing I've done has shown as much as 15%
> of overhead in the lock_sock/release_sock part, with this change then
> we see none.
>
> Comments welcome!
>
How BH handlers (including TCP timers) and io_uring are going to run 
safely ?

Even if a tcp socket had one user, (private fd opened by a non 
multi-threaded

program), we would still to use the spinlock.


Maybe I am missing something, but so far your patches make no sense to me.



  parent reply	other threads:[~2022-04-13  0:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 20:26 [PATCHSET 0/4] Add support for no-lock sockets Jens Axboe
2022-04-12 20:26 ` [PATCH 1/4] net: add sock 'sk_no_lock' member Jens Axboe
2022-04-12 20:26 ` [PATCH 2/4] net: allow sk_prot->release_cb() without sock lock held Jens Axboe
2022-04-12 20:26 ` [PATCH 3/4] net: add support for socket no-lock Jens Axboe
2022-04-12 20:26 ` [PATCH 4/4] io_uring: mark accept direct socket as no-lock Jens Axboe
2022-04-13  0:40 ` Eric Dumazet [this message]
2022-04-13  1:26   ` [PATCHSET 0/4] Add support for no-lock sockets Jens Axboe
2022-04-13  1:54     ` Eric Dumazet
2022-04-13  2:01       ` Jens Axboe
2022-04-13  2:05         ` Eric Dumazet
2022-04-13  2:12           ` Jens Axboe
2022-04-13  2:19             ` Eric Dumazet
2022-04-13  2:26               ` Eric Dumazet
2022-04-13  2:27               ` Jens Axboe
2022-04-13  2:32                 ` Eric Dumazet
2022-04-13  2:38                   ` Jens Axboe
2022-04-13  5:23         ` dust.li
2022-04-13  7:53           ` Paolo Abeni

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=e7631a6f-b614-da4c-4f47-571a7b0149fc@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=edumazet@google.com \
    --cc=io-uring@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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.