From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: xuanzhuo@linux.alibaba.com, edumazet@google.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Maxime Coquelin <maxime.coquelin@redhat.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: Thu, 27 Jul 2023 05:46:45 -0400 [thread overview]
Message-ID: <20230727054300-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEuEFG-vT0xqddRAn2=V+4kayVG7NFVpB96vmecy0TLOWw@mail.gmail.com>
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.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@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: Thu, 27 Jul 2023 05:46:45 -0400 [thread overview]
Message-ID: <20230727054300-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEuEFG-vT0xqddRAn2=V+4kayVG7NFVpB96vmecy0TLOWw@mail.gmail.com>
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.
--
MST
next prev parent reply other threads:[~2023-07-27 9:46 UTC|newest]
Thread overview: 82+ 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 ` 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 8:38 ` Jason Wang
2023-07-20 20:25 ` Shannon Nelson via Virtualization
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 8:38 ` Jason Wang
2023-07-20 15:31 ` Shannon Nelson via Virtualization
2023-07-20 15:31 ` Shannon Nelson
2023-07-20 20:58 ` Michael S. Tsirkin
2023-07-20 20:58 ` Michael S. Tsirkin
2023-07-20 20:26 ` Shannon Nelson via Virtualization
2023-07-20 20:26 ` Shannon Nelson
2023-07-20 21:02 ` Michael S. Tsirkin
2023-07-20 21:02 ` Michael S. Tsirkin
2023-07-21 14:37 ` Maxime Coquelin
2023-07-21 14:37 ` Maxime Coquelin
2023-07-21 14:45 ` Michael S. Tsirkin
2023-07-21 14:45 ` Michael S. Tsirkin
2023-07-21 14:58 ` Maxime Coquelin
2023-07-21 14:58 ` Maxime Coquelin
2023-07-21 15:10 ` Michael S. Tsirkin
2023-07-21 15:10 ` Michael S. Tsirkin
2023-07-21 20:18 ` Maxime Coquelin
2023-07-21 20:18 ` Maxime Coquelin
2023-07-24 6:46 ` Michael S. Tsirkin
2023-07-24 6:46 ` Michael S. Tsirkin
2023-07-24 6:52 ` Jason Wang
2023-07-24 6:52 ` Jason Wang
2023-07-24 7:18 ` Michael S. Tsirkin
2023-07-24 7:18 ` Michael S. Tsirkin
2023-07-25 3:03 ` Jason Wang
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 via Virtualization
2023-10-05 19:35 ` Feng Liu
2023-10-08 5:27 ` Jason Wang
2023-10-08 5:27 ` Jason Wang
2023-07-24 6:52 ` Jason Wang
2023-07-24 6:52 ` Jason Wang
2023-07-24 7:17 ` Michael S. Tsirkin
2023-07-24 7:17 ` Michael S. Tsirkin
2023-07-25 3:07 ` Jason Wang
2023-07-25 3:07 ` Jason Wang
2023-07-25 7:36 ` Michael S. Tsirkin
2023-07-25 7:36 ` Michael S. Tsirkin
2023-07-26 1:55 ` Jason Wang
2023-07-26 1:55 ` Jason Wang
2023-07-26 11:37 ` Michael S. Tsirkin
2023-07-26 11:37 ` Michael S. Tsirkin
2023-07-27 6:03 ` Jason Wang
2023-07-27 6:03 ` Jason Wang
2023-07-27 6:10 ` Michael S. Tsirkin
2023-07-27 6:10 ` Michael S. Tsirkin
2023-07-27 8:59 ` Jason Wang
2023-07-27 8:59 ` Jason Wang
2023-07-27 9:46 ` Michael S. Tsirkin [this message]
2023-07-27 9:46 ` Michael S. Tsirkin
2023-07-31 6:30 ` Jason Wang
2023-07-31 6:30 ` Jason Wang
2023-08-08 2:30 ` Jason Wang
2023-08-08 2:30 ` Jason Wang
2023-08-10 19:41 ` Michael S. Tsirkin
2023-08-10 19:41 ` Michael S. Tsirkin
2023-08-11 2:23 ` Jason Wang
2023-08-11 2:23 ` Jason Wang
2023-08-11 5:42 ` Michael S. Tsirkin
2023-08-11 5:42 ` Michael S. Tsirkin
2023-08-11 9:18 ` Jason Wang
2023-08-11 9:18 ` Jason Wang
2023-08-11 9:21 ` Michael S. Tsirkin
2023-08-11 9:21 ` Michael S. Tsirkin
2023-08-11 9:43 ` Jason Wang
2023-08-11 9:43 ` Jason Wang
2023-08-11 9:51 ` Michael S. Tsirkin
2023-08-11 9:51 ` Michael S. Tsirkin
2023-08-11 9:54 ` Jason Wang
2023-08-11 9:54 ` Jason Wang
2023-08-11 10:12 ` Michael S. Tsirkin
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=20230727054300-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.coquelin@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.