qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Ilya Maximets <i.maximets@ovn.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Eric Blake <eblake@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] net: add initial support for AF_XDP network backend
Date: Wed, 28 Jun 2023 09:45:42 +0200	[thread overview]
Message-ID: <CAJSP0QXPiNK2rH6_8bB7sjMpdQjT--oX0u4FkdaTj7Ew3qs8CA@mail.gmail.com> (raw)
In-Reply-To: <CACGkMEsE6_91mOhCP5ezT96zz-Tb-bLXQr9ktrLg6zG0TZC3Lg@mail.gmail.com>

On Wed, 28 Jun 2023 at 05:28, Jason Wang <jasowang@redhat.com> wrote:
>
> On Wed, Jun 28, 2023 at 6:45 AM Ilya Maximets <i.maximets@ovn.org> wrote:
> >
> > On 6/27/23 04:54, Jason Wang wrote:
> > > On Mon, Jun 26, 2023 at 9:17 PM Ilya Maximets <i.maximets@ovn.org> wrote:
> > >>
> > >> On 6/26/23 08:32, Jason Wang wrote:
> > >>> On Sun, Jun 25, 2023 at 3:06 PM Jason Wang <jasowang@redhat.com> wrote:
> > >>>>
> > >>>> On Fri, Jun 23, 2023 at 5:58 AM Ilya Maximets <i.maximets@ovn.org> wrote:
> > >> It is noticeably more performant than a tap with vhost=on in terms of PPS.
> > >> So, that might be one case.  Taking into account that just rcu lock and
> > >> unlock in virtio-net code takes more time than a packet copy, some batching
> > >> on QEMU side should improve performance significantly.  And it shouldn't be
> > >> too hard to implement.
> > >>
> > >> Performance over virtual interfaces may potentially be improved by creating
> > >> a kernel thread for async Tx.  Similarly to what io_uring allows.  Currently
> > >> Tx on non-zero-copy interfaces is synchronous, and that doesn't allow to
> > >> scale well.
> > >
> > > Interestingly, actually, there are a lot of "duplication" between
> > > io_uring and AF_XDP:
> > >
> > > 1) both have similar memory model (user register)
> > > 2) both use ring for communication
> > >
> > > I wonder if we can let io_uring talks directly to AF_XDP.
> >
> > Well, if we submit poll() in QEMU main loop via io_uring, then we can
> > avoid cost of the synchronous Tx for non-zero-copy modes, i.e. for
> > virtual interfaces.  io_uring thread in the kernel will be able to
> > perform transmission for us.
>
> It would be nice if we can use iothread/vhost other than the main loop
> even if io_uring can use kthreads. We can avoid the memory translation
> cost.

The QEMU event loop (AioContext) has io_uring code
(utils/fdmon-io_uring.c) but it's disabled at the moment. I'm working
on patches to re-enable it and will probably send them in July. The
patches also add an API to submit arbitrary io_uring operations so
that you can do stuff besides file descriptor monitoring. Both the
main loop and IOThreads will be able to use io_uring on Linux hosts.

Stefan


  reply	other threads:[~2023-06-28  7:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 21:58 [PATCH] net: add initial support for AF_XDP network backend Ilya Maximets
2023-06-25  7:06 ` Jason Wang
2023-06-26  6:32   ` Jason Wang
2023-06-26 13:12     ` Ilya Maximets
2023-06-27  2:54       ` Jason Wang
2023-06-27 22:46         ` Ilya Maximets
2023-06-28  3:27           ` Jason Wang
2023-06-28  7:45             ` Stefan Hajnoczi [this message]
2023-06-28  7:59               ` Jason Wang
2023-06-28  8:14                 ` Stefan Hajnoczi
2023-06-28  8:18                   ` Jason Wang
2023-06-28  8:25                     ` Stefan Hajnoczi
2023-06-29  5:25                       ` Jason Wang
2023-06-29 12:35                         ` Stefan Hajnoczi
2023-06-30  7:41                           ` Jason Wang
2023-07-03  9:03                             ` Stefan Hajnoczi
2023-07-05  6:02                               ` Jason Wang
2023-07-06 19:08                                 ` Stefan Hajnoczi
2023-07-07  1:43                                   ` Jason Wang
2023-07-07 11:21                                     ` Ilya Maximets
2023-07-10  3:51                                       ` Jason Wang
2023-07-10 10:56                                         ` Ilya Maximets
2023-07-10 15:21                                           ` Stefan Hajnoczi
2023-07-11  3:02                                             ` Jason Wang
2023-07-11  3:00                                           ` Jason Wang
2023-07-10 15:14                                     ` Stefan Hajnoczi
2023-07-11  3:04                                       ` Jason Wang
2023-06-28 11:15             ` Ilya Maximets
2023-06-30  7:44               ` Jason Wang
2023-06-30 15:01                 ` Ilya Maximets
2023-06-27  8:56 ` Stefan Hajnoczi
2023-06-27 23:10   ` Ilya Maximets

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=CAJSP0QXPiNK2rH6_8bB7sjMpdQjT--oX0u4FkdaTj7Ew3qs8CA@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=eblake@redhat.com \
    --cc=i.maximets@ovn.org \
    --cc=jasowang@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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.
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).