From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Jason Wang <jasowang@redhat.com>,
Jason Xing <kerneljasonxing@gmail.com>,
Heng Qi <hengqi@linux.alibaba.com>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, xuanzhuo@linux.alibaba.com,
virtualization@lists.linux.dev, ast@kernel.org,
daniel@iogearbox.net, hawk@kernel.org, john.fastabend@gmail.com,
netdev@vger.kernel.org
Subject: Re: [patch net-next] virtio_net: add support for Byte Queue Limits
Date: Mon, 10 Jun 2024 10:18:56 -0400 [thread overview]
Message-ID: <20240610101346-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ZmLvWnzUBwgpbyeh@nanopsycho.orion>
On Fri, Jun 07, 2024 at 01:30:34PM +0200, Jiri Pirko wrote:
> Fri, Jun 07, 2024 at 12:23:37PM CEST, mst@redhat.com wrote:
> >On Fri, Jun 07, 2024 at 11:57:37AM +0200, Jiri Pirko wrote:
> >> >True. Personally, I would like to just drop orphan mode. But I'm not
> >> >sure others are happy with this.
> >>
> >> How about to do it other way around. I will take a stab at sending patch
> >> removing it. If anyone is against and has solid data to prove orphan
> >> mode is needed, let them provide those.
> >
> >Break it with no warning and see if anyone complains?
>
> This is now what I suggested at all.
>
> >No, this is not how we handle userspace compatibility, normally.
>
> Sure.
>
> Again:
>
> I would send orphan removal patch containing:
> 1) no module options removal. Warn if someone sets it up
> 2) module option to disable napi is ignored
> 3) orphan mode is removed from code
>
> There is no breakage. Only, hypotetically performance downgrade in some
> hypotetical usecase nobody knows of.
Performance is why people use virtio. It's as much a breakage as any
other bug. The main difference is, with other types of breakage, they
are typically binary and we can not tolerate them at all. A tiny,
negligeable performance regression might be tolarable if it brings
other benefits. I very much doubt avoiding interrupts is
negligeable though. And making code simpler isn't a big benefit,
users do not care.
> My point was, if someone presents
> solid data to prove orphan is needed during the patch review, let's toss
> out the patch.
>
> Makes sense?
It's not hypothetical - if anything, it's hypothetical that performance
does not regress. And we just got a report from users that see a
regression without. So, not really.
>
> >
> >--
> >MST
> >
next prev parent reply other threads:[~2024-06-10 14:19 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 11:46 [patch net-next] virtio_net: add support for Byte Queue Limits Jiri Pirko
2024-05-09 12:41 ` Michael S. Tsirkin
2024-05-09 13:31 ` Jiri Pirko
2024-05-09 14:28 ` Michael S. Tsirkin
2024-05-10 4:25 ` Jason Wang
2024-05-10 10:37 ` Jiri Pirko
2024-05-10 10:52 ` Michael S. Tsirkin
2024-05-10 11:11 ` Jiri Pirko
2024-05-10 11:27 ` Michael S. Tsirkin
2024-05-10 11:36 ` Jiri Pirko
2024-05-15 7:34 ` Jiri Pirko
2024-05-15 8:20 ` Michael S. Tsirkin
2024-05-15 10:12 ` Jiri Pirko
2024-05-15 12:54 ` Jiri Pirko
2024-05-16 4:48 ` Jason Wang
2024-05-16 10:54 ` Jiri Pirko
2024-05-16 12:31 ` Michael S. Tsirkin
2024-05-16 15:25 ` Jiri Pirko
2024-05-16 19:04 ` Michael S. Tsirkin
2024-05-17 7:52 ` Jiri Pirko
[not found] ` <CAA93jw6WanAQrPAFZ1hYVTXuWDwP+4J70LnmPOD2ugNwYK6HMA@mail.gmail.com>
2024-06-06 7:30 ` Jiri Pirko
2024-05-10 4:25 ` Jason Wang
2024-05-10 7:11 ` Heng Qi
2024-05-10 10:35 ` Jiri Pirko
2024-05-20 12:48 ` Jiri Pirko
2024-06-05 11:30 ` Jiri Pirko
2024-06-05 11:42 ` Heng Qi
2024-06-06 0:20 ` Jason Wang
2024-06-06 2:58 ` Jason Xing
2024-06-06 4:25 ` Jason Wang
2024-06-06 6:05 ` Michael S. Tsirkin
2024-06-06 7:56 ` Jason Wang
2024-06-06 13:45 ` Jiri Pirko
2024-06-07 6:25 ` Jason Wang
2024-06-07 6:39 ` Jiri Pirko
2024-06-07 6:43 ` Michael S. Tsirkin
2024-06-07 6:47 ` Jason Wang
2024-06-07 9:57 ` Jiri Pirko
2024-06-07 10:23 ` Michael S. Tsirkin
2024-06-07 11:30 ` Jiri Pirko
2024-06-10 14:18 ` Michael S. Tsirkin [this message]
2024-06-17 1:44 ` Jason Wang
2024-06-17 9:30 ` Jiri Pirko
2024-06-17 16:16 ` Michael S. Tsirkin
2024-06-18 1:19 ` Jason Wang
2024-06-18 0:52 ` Jason Wang
2024-06-18 18:23 ` Michael S. Tsirkin
2024-06-17 16:18 ` Michael S. Tsirkin
2024-06-07 11:22 ` Jason Xing
2024-06-06 11:42 ` Jason Xing
2024-06-06 12:00 ` Michael S. Tsirkin
2024-06-06 13:41 ` Jiri Pirko
2024-06-07 6:22 ` Jason Wang
2024-06-07 6:39 ` Michael S. Tsirkin
2024-06-07 6:40 ` Jiri Pirko
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=20240610101346-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux.dev \
--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.