linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Lutomirski' <luto@amacapital.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	network dev <netdev@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: recvfrom/recvmsg performance and CONFIG_HARDENED_USERCOPY
Date: Tue, 10 Dec 2019 10:21:49 +0000	[thread overview]
Message-ID: <5a3cf731da8442909a4b84d975beb5e0@AcuMS.aculab.com> (raw)
In-Reply-To: <F6840B11-060A-48F2-9FFE-774E73C50765@amacapital.net>

From: Andy Lutomirski
> Sent: 09 December 2019 18:43
> 
> > On Dec 9, 2019, at 3:01 AM, David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Eric Dumazet
> >> Sent: 06 December 2019 14:22
> > ...
> >> Real question is : Do you actually need to use recvmsg() instead of recvfrom() ?
> >> If recvmsg() provides additional cmsg, this is not surprising it is more expensive.
> >
> > Except I'm not passing in a buffer for it.
> > The reason I'm looking at recvmsg is that I'd like to use recvmmsg it order to
> > read out more than one message from a socket without doing an extra poll().
> > Note that I don't expect there to be a second message most of the time and
> > almost never a third one.
> >
> > Although I think that will only ever 'win' if recvmmsg() called vfs_poll() to find
> > if there was more data to read before doing any of the copy_from_user() etc
> 
> I would suggest a more general improvement: add a -EAGAIN fast path to recvmsg().
> If the socket is nonblocking and has no data to
> read, then there shouldn’t be a need to process the iovec at all.

You don't want to do that for recvmsg() itself.
It will normally only be called if poll() reported data is available.
Actually the MSG_WAITFORONE flag could be used to do a call
to vfs_poll() before the subsequent calls to __sys_recvmsg().
This will work for non-blocking sockets (or even calls with both
MSG_DONTWAIT and MSG_WAITFORONE set).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2019-12-10 10:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06 13:39 recvfrom/recvmsg performance and CONFIG_HARDENED_USERCOPY David Laight
2019-12-06 14:21 ` Eric Dumazet
2019-12-06 16:09   ` Paolo Abeni
2019-12-06 16:19     ` Eric Dumazet
2019-12-09 11:01   ` David Laight
2019-12-09 18:43     ` Andy Lutomirski
2019-12-10 10:21       ` David Laight [this message]
2019-12-09 15:05 ` 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=5a3cf731da8442909a4b84d975beb5e0@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=netdev@vger.kernel.org \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).