From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
Thibaut Collet <thibaut.collet@6wind.com>
Subject: Re: [PATCH] vhost-user: Silence unsupported VHOST_USER_PROTOCOL_F_RARP error
Date: Thu, 20 Feb 2025 15:45:50 -0500 [thread overview]
Message-ID: <20250220154353-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20250220210004.1501dd86@elisabeth>
On Thu, Feb 20, 2025 at 09:00:04PM +0100, Stefano Brivio wrote:
> On Thu, 20 Feb 2025 13:21:33 -0500
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Feb 20, 2025 at 05:59:10PM +0100, Stefano Brivio wrote:
> > > On Thu, 20 Feb 2025 10:28:20 -0500
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > > > On Fri, Jan 24, 2025 at 05:03:27PM +0100, Stefano Brivio wrote:
> > > > > But I don't understand why we're leaving this as it is.
> > > >
> > > > So that people notice if there's some backend problem and
> > > > announcements are not going out. should help debug migration
> > > > issues. which we had, so we added this :)
> > >
> > > The message mentions that the back-end fails to do something it didn't
> > > and can't even do, that's (one reason) why it's wrong (and confusing)
> > > and this patch is obviously correct.
> > >
> > > Perhaps the commit title isn't entirely accurate (it should say "when
> > > unsupported", I guess) but it's somewhat expected to sacrifice detail
> > > in the name of brevity, there. A glimpse at the message is enough.
> > >
> > > Laurent now added a workaround in passt to pretend that we support
> > > VHOST_USER_PROTOCOL_F_RARP by doing nothing in the callback, report
> > > success, and silence the warning:
> > >
> > > https://passt.top/passt/commit/?id=dd6a6854c73a09c4091c1776ee7f349d1e1f966c
> > >
> > > but having to do this kind of stuff is a bit unexpected while
> > > interacting with another opensource project.
> > >
> > > --
> > > Stefano
> >
> >
> > let me explain. historically backends did not support migration.
> > then migration was added. as it was assumed RARP is required,
> > we did not add a feature flag for "supports migration" and
> > instead just assumed that VHOST_USER_PROTOCOL_F_RARP is that.
> >
> > If you silence the warning you silence it for old backends
> > with no migration support.
>
> Thanks for the explanation. I'm struggling to grasp this. So if a
> back-end doesn't support migration, because VHOST_USER_PROTOCOL_F_RARP
> is not present in the features flag, migration is done anyway, but then
> this is printed:
>
> Vhost user backend fails to broadcast fake RARP
>
> with the meaning of:
>
> We did migration even if the back-end doesn't support it, whoops
>
> ?
>
> Note that the message is printed *after* the migration and the flag is
> *not* checked before.
>
> > If you want a new flag "migration with no RARP", be my
> > guest and add it.
>
> That would actually make more sense than the existing situation I
> think. VHOST_USER_PROTOCOL_F_NO_RARP?
>
> I didn't understand, yet, what the exact meaning would be, though.
>
> > Or if you want to add documentation explaining the meaning
> > better and clarifying the message.
>
> I'm still in the phase where I'm trying to understand the role of the
> message :) ...I have to say this is fairly different now from what was
> mentioned on the thread so far.
I'm going by memory. We made it a warning on the assumption that hey,
maybe someone has a way to migrate without a RARP, let them work.
Exactly what happened, we just did not think it through completely :)
--
MST
next prev parent reply other threads:[~2025-02-20 20:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 10:00 [PATCH] vhost-user: Silence unsupported VHOST_USER_PROTOCOL_F_RARP error Laurent Vivier
2025-01-22 13:42 ` Stefano Garzarella
2025-01-22 13:59 ` Michael S. Tsirkin
2025-01-22 16:20 ` Stefano Garzarella
2025-01-22 16:29 ` Michael S. Tsirkin
2025-01-22 16:41 ` Laurent Vivier
2025-01-22 16:51 ` Stefano Garzarella
2025-01-22 17:22 ` Laurent Vivier
2025-01-22 17:30 ` Daniel P. Berrangé
2025-01-24 16:03 ` Stefano Brivio
2025-02-20 15:28 ` Michael S. Tsirkin
2025-02-20 16:59 ` Stefano Brivio
2025-02-20 18:21 ` Michael S. Tsirkin
2025-02-20 20:00 ` Stefano Brivio
2025-02-20 20:45 ` Michael S. Tsirkin [this message]
2025-02-21 1:18 ` Jason Wang
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=20250220154353-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sbrivio@redhat.com \
--cc=sgarzare@redhat.com \
--cc=thibaut.collet@6wind.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.