From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>,
Shannon Nelson <shannon.nelson@amd.com>,
xuanzhuo@linux.alibaba.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net
Subject: Re: [PATCH net-next v4 2/2] virtio-net: add cond_resched() to the command waiting loop
Date: Fri, 11 Aug 2023 17:18:51 +0800 [thread overview]
Message-ID: <CACGkMEu8gCJGa4aLTrrNdCRYrZXohF0Pdx3a9kBhrhcHyt05-Q@mail.gmail.com> (raw)
In-Reply-To: <20230811012147-mutt-send-email-mst@kernel.org>
On Fri, Aug 11, 2023 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Aug 11, 2023 at 10:23:15AM +0800, Jason Wang wrote:
> > On Fri, Aug 11, 2023 at 3:41 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Tue, Aug 08, 2023 at 10:30:56AM +0800, Jason Wang wrote:
> > > > On Mon, Jul 31, 2023 at 2:30 PM Jason Wang <jasowang@redhat.com> wrote:
> > > > >
> > > > > On Thu, Jul 27, 2023 at 5:46 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > >
> > > > > > On Thu, Jul 27, 2023 at 04:59:33PM +0800, Jason Wang wrote:
> > > > > > > > They really shouldn't - any NIC that takes forever to
> > > > > > > > program will create issues in the networking stack.
> > > > > > >
> > > > > > > Unfortunately, it's not rare as the device/cvq could be implemented
> > > > > > > via firmware or software.
> > > > > >
> > > > > > Currently that mean one either has sane firmware with a scheduler that
> > > > > > can meet deadlines, or loses ability to report errors back.
> > > > > >
> > > > > > > > But if they do they can always set this flag too.
> > > > > > >
> > > > > > > This may have false negatives and may confuse the management.
> > > > > > >
> > > > > > > Maybe we can extend the networking core to allow some device specific
> > > > > > > configurations to be done with device specific lock without rtnl. For
> > > > > > > example, split the set_channels to
> > > > > > >
> > > > > > > pre_set_channels
> > > > > > > set_channels
> > > > > > > post_set_channels
> > > > > > >
> > > > > > > The device specific part could be done in pre and post without a rtnl lock?
> > > > > > >
> > > > > > > Thanks
> > > > > >
> > > > > >
> > > > > > Would the benefit be that errors can be reported to userspace then?
> > > > > > Then maybe. I think you will have to show how this works for at least
> > > > > > one card besides virtio.
> > > > >
> > > > > Even for virtio, this seems not easy, as e.g the
> > > > > virtnet_send_command() and netif_set_real_num_tx_queues() need to
> > > > > appear to be atomic to the networking core.
> > > > >
> > > > > I wonder if we can re-consider the way of a timeout here and choose a
> > > > > sane value as a start.
> > > >
> > > > Michael, any more input on this?
> > > >
> > > > Thanks
> > >
> > > I think this is just mission creep. We are trying to fix
> > > vduse - let's do that for starters.
> > >
> > > Recovering from firmware timeouts is far from trivial and
> > > just assuming that just because it timed out it will not
> > > access memory is just as likely to cause memory corruption
> > > with worse results than an infinite spin.
> >
> > Yes, this might require support not only in the driver
> >
> > >
> > > I propose we fix this for vduse and assume hardware/firmware
> > > is well behaved.
> >
> > One major case is the re-connection, in that case it might take
> > whatever longer that the kernel virito-net driver expects.
> > So we can have a timeout in VDUSE and trap CVQ then VDUSE can return
> > and fail early?
>
> Ugh more mission creep. not at all my point. vduse should cache
> values in the driver,
What do you mean by values here? The cvq command?
Thanks
> until someone manages to change
> net core to be more friendly to userspace devices.
>
> >
> > > Or maybe not well behaved firmware will
> > > set the flag losing error reporting ability.
> >
> > This might be hard since it means not only the set but also the get is
> > unreliable.
> >
> > Thanks
>
> /me shrugs
>
>
>
> > >
> > >
> > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > MST
> > > > > >
> > >
>
next prev parent reply other threads:[~2023-08-11 9:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 8:38 [PATCH net-next v4 0/2] virtio-net: don't busy poll for cvq command Jason Wang
2023-07-20 8:38 ` [PATCH net-next v4 1/2] virtio-net: convert rx mode setting to use workqueue Jason Wang
2023-07-20 20:25 ` Shannon Nelson
2023-07-20 8:38 ` [PATCH net-next v4 2/2] virtio-net: add cond_resched() to the command waiting loop Jason Wang
2023-07-20 15:31 ` Shannon Nelson
2023-07-20 20:58 ` Michael S. Tsirkin
2023-07-20 20:26 ` Shannon Nelson
2023-07-20 21:02 ` Michael S. Tsirkin
2023-07-21 14:37 ` Maxime Coquelin
2023-07-21 14:45 ` Michael S. Tsirkin
2023-07-21 14:58 ` Maxime Coquelin
2023-07-21 15:10 ` Michael S. Tsirkin
2023-07-21 20:18 ` Maxime Coquelin
2023-07-24 6:46 ` Michael S. Tsirkin
2023-07-24 6:52 ` Jason Wang
2023-07-24 7:18 ` Michael S. Tsirkin
2023-07-25 3:03 ` Jason Wang
2024-02-22 19:21 ` Michael S. Tsirkin
2024-02-26 5:08 ` Jason Wang
2023-10-05 19:35 ` Feng Liu
2023-10-08 5:27 ` Jason Wang
2023-07-24 6:52 ` Jason Wang
2023-07-24 7:17 ` Michael S. Tsirkin
2023-07-25 3:07 ` Jason Wang
2023-07-25 7:36 ` Michael S. Tsirkin
2023-07-26 1:55 ` Jason Wang
2023-07-26 11:37 ` Michael S. Tsirkin
2023-07-27 6:03 ` Jason Wang
2023-07-27 6:10 ` Michael S. Tsirkin
2023-07-27 8:59 ` Jason Wang
2023-07-27 9:46 ` Michael S. Tsirkin
2023-07-31 6:30 ` Jason Wang
2023-08-08 2:30 ` Jason Wang
2023-08-10 19:41 ` Michael S. Tsirkin
2023-08-11 2:23 ` Jason Wang
2023-08-11 5:42 ` Michael S. Tsirkin
2023-08-11 9:18 ` Jason Wang [this message]
2023-08-11 9:21 ` Michael S. Tsirkin
2023-08-11 9:43 ` Jason Wang
2023-08-11 9:51 ` Michael S. Tsirkin
2023-08-11 9:54 ` Jason Wang
2023-08-11 10:12 ` Michael S. Tsirkin
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=CACGkMEu8gCJGa4aLTrrNdCRYrZXohF0Pdx3a9kBhrhcHyt05-Q@mail.gmail.com \
--to=jasowang@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shannon.nelson@amd.com \
--cc=virtualization@lists.linux-foundation.org \
--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).