virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Eugenio Perez Martin <eperezma@redhat.com>,
	Maxime Coquelin <mcoqueli@redhat.com>,
	Yongji Xie <xieyongji@bytedance.com>,
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	Dragos Tatulea DE <dtatulea@nvidia.com>
Subject: Re: [RFC 1/2] virtio_net: timeout control virtqueue commands
Date: Thu, 16 Oct 2025 02:22:03 -0400	[thread overview]
Message-ID: <20251016022131-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEtXWLicmszjkzOhX8Ta=LdGgsDahRUKDEVzBVG8am5vgg@mail.gmail.com>

On Thu, Oct 16, 2025 at 02:03:57PM +0800, Jason Wang wrote:
> On Thu, Oct 16, 2025 at 1:45 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Oct 16, 2025 at 01:39:58PM +0800, Jason Wang wrote:
> > > > >
> > > > > Not exactly bufferize, record.  E.g. we do not need to send
> > > > > 100 messages to enable/disable promisc mode - together they
> > > > > have no effect.
> > >
> > > Note that there's a case that multiple commands need to be sent, e.g
> > > set rx mode. And assuming not all the commands are the best effort,
> > > kernel VDUSE still needs to wait for the usersapce at least for a
> > > while.
> >
> > Not wait, record. Generate 1st command, after userspace consumed it -
> > generate and send second command and so on.
> 
> Right, that's what I asked in another thread, we still need a timeout
> here.

we do not need a timeout.

> Then I think it would not be too much difference whether it is
> VDUSE or CVQ that will fail or break the device. Conceptually, VDUSE
> can only advertise NEEDS_RESET since it's a device implementation.
> VDUSE can not simply break the device as it requires synchronization
> which is not easy.
> 
> > But for each bit of data, at most one command has to be sent,
> > we do not care if guest tweaked rx mode 3 times, we only care about
> > the latest state.
> 
> Yes, but I want to know what's best when VDUSE meets userspace timeout.
> 
> Thanks


userspace should manage its own timeouts.

> >
> > --
> > MST
> >


  reply	other threads:[~2025-10-16  6:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-07 13:06 [RFC 0/2] Lift restriction about VDUSE net devices with CVQ Eugenio Pérez
2025-10-07 13:06 ` [RFC 1/2] virtio_net: timeout control virtqueue commands Eugenio Pérez
2025-10-11  7:44   ` Jason Wang
2025-10-14  7:30     ` Eugenio Perez Martin
2025-10-14  8:29   ` Michael S. Tsirkin
2025-10-14  9:14     ` Maxime Coquelin
2025-10-14  9:25       ` Michael S. Tsirkin
2025-10-14 10:21         ` Maxime Coquelin
2025-10-15  4:44           ` Jason Wang
2025-10-15  6:07             ` Michael S. Tsirkin
2025-10-15  6:08         ` Eugenio Perez Martin
2025-10-15  6:33           ` Michael S. Tsirkin
2025-10-15  6:52             ` Eugenio Perez Martin
2025-10-15  7:04               ` Michael S. Tsirkin
2025-10-15  7:45                 ` Eugenio Perez Martin
2025-10-15  8:03                   ` Maxime Coquelin
2025-10-15  8:09                     ` Michael S. Tsirkin
2025-10-15  9:16                       ` Maxime Coquelin
2025-10-15 10:36                       ` Eugenio Perez Martin
2025-10-16  5:39                         ` Jason Wang
2025-10-16  5:45                           ` Michael S. Tsirkin
2025-10-16  6:03                             ` Jason Wang
2025-10-16  6:22                               ` Michael S. Tsirkin [this message]
2025-10-16  6:25                                 ` Eugenio Perez Martin
2025-10-17  6:36                                   ` Eugenio Perez Martin
2025-10-17  6:39                                     ` Michael S. Tsirkin
2025-10-17  7:21                                       ` Eugenio Perez Martin
2025-10-22  9:46                                         ` Eugenio Perez Martin
2025-10-22 10:06                                         ` Michael S. Tsirkin
2025-10-22 10:09                         ` Michael S. Tsirkin
2025-10-22 10:50                           ` Eugenio Perez Martin
2025-10-22 11:43                             ` Michael S. Tsirkin
2025-10-22 12:55                               ` Eugenio Perez Martin
2025-10-28 14:09                                 ` Michael S. Tsirkin
2025-10-28 14:37                                   ` Eugenio Perez Martin
2025-10-28 14:42                                     ` Michael S. Tsirkin
2025-10-28 14:57                                       ` Eugenio Perez Martin
2025-10-29  0:36                                         ` Jason Wang
2025-11-05  9:02                                         ` Eugenio Perez Martin
2025-11-09 21:46                                           ` Michael S. Tsirkin
2025-10-07 13:06 ` [RFC 2/2] vduse: lift restriction about net devices with CVQ Eugenio Pérez
2025-10-09 13:14   ` Maxime Coquelin
2025-10-15  6:11     ` Eugenio Perez Martin
2025-10-14  8:31   ` Michael S. Tsirkin
2025-10-15  6:25     ` Eugenio Perez Martin

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=20251016022131-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=dtatulea@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcoqueli@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xieyongji@bytedance.com \
    --cc=xuanzhuo@linux.alibaba.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).