From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 3/5] tap: Don't use EPOLLET on Qemu sockets
Date: Mon, 29 Jul 2024 11:15:41 +1000 [thread overview]
Message-ID: <ZqbtPQbXYeEMrGnZ@zatzit> (raw)
In-Reply-To: <20240726152518.7daab5bc@elisabeth>
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
On Fri, Jul 26, 2024 at 03:25:38PM +0200, Stefano Brivio wrote:
> On Fri, 26 Jul 2024 22:12:27 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Fri, Jul 26, 2024 at 10:00:56AM +0200, Stefano Brivio wrote:
> > > On Fri, 26 Jul 2024 17:20:29 +1000
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > Currently we set EPOLLET (edge trigger) on the epoll flags for the
> > > > connected Qemu Unix socket. It's not clear that there's a reason for
> > > > doing this: for TCP sockets we need to use EPOLLET, because we leave data
> > > > in the socket buffers for our flow control handling. That consideration
> > > > doesn't apply to the way we handle the qemu socket however.
> > >
> > > It significantly decreases epoll_wait() overhead on sustained data
> > > transfers, because we can read multiple TAP_BUF_SIZE buffers at a time
> > > instead of just one.
> >
> > That's a reason to keep the loop, but not EPOLLET itself, AFAICT. I'd
> > be happy enough to put the loop back in as an optimization (although,
> > I'd prefer to avoid the goto).
>
> True, we could actually have that loop back without EPOLLET.
>
> But the reason why I added EPOLLET, despite the resulting complexity,
> was surely increased overhead without it.
>
> I can't remember (and unfortunately I didn't write this in that commit
> message from 2021) exactly how that looked like, if we had spurious or
> more frequent wake-ups or what else. Maybe that was a side effect of
> something that's fixed or otherwise changed now, but still we should
> give this a pass with perf(1) before we try to optimise this again (if
> it even needs to be optimised, that is).
I think we need to understand if and why that's still the case before
putting this back in. I can see an obvious reason why the loop might
reduce overhead, but not why the EPOLLET flag itself would. If
anything I'd expect level triggered events to more accurately give us
wakeups only exactly when we need them.
Note also that even looping withouth EPOLLET does have its own cost
here: it potentially allows a heavy burst of traffic from qemu to
starve processing of events on other sockets.
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-29 1:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 7:20 [PATCH 0/5] Fix assorted errors in the Qemu socket tap receive handler David Gibson
2024-07-26 7:20 ` [PATCH 1/5] tap: Better report errors receiving from QEMU socket David Gibson
2024-07-26 11:25 ` Stefano Brivio
2024-07-26 11:50 ` Stefano Brivio
2024-07-26 12:02 ` David Gibson
2024-07-26 7:20 ` [PATCH 2/5] tap: Don't attempt to carry on if we get a bad frame length from qemu David Gibson
2024-07-26 11:26 ` Stefano Brivio
2024-07-26 7:20 ` [PATCH 3/5] tap: Don't use EPOLLET on Qemu sockets David Gibson
2024-07-26 8:00 ` Stefano Brivio
2024-07-26 10:44 ` Stefano Brivio
2024-07-26 12:12 ` David Gibson
2024-07-26 13:25 ` Stefano Brivio
2024-07-29 1:15 ` David Gibson [this message]
2024-07-26 7:20 ` [PATCH 4/5] tap: Correctly handle frames of odd length David Gibson
2024-07-26 7:20 ` [PATCH 5/5] tap: Improve handling of partially received frames on qemu socket David Gibson
2024-07-26 11:39 ` Stefano Brivio
2024-07-26 12:33 ` David Gibson
2024-07-26 13:19 ` [PATCH 0/5] Fix assorted errors in the Qemu socket tap receive handler Stefano Brivio
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=ZqbtPQbXYeEMrGnZ@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.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.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
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 IMAP folder(s).