On Fri, Feb 21, 2025 at 4:46 AM Michael S. Tsirkin <[email protected]> wrote: > > 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" <[email protected]> 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" <[email protected]> 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.
Migration still works, it might just increase the time spent on recovering the networking topology by switching if the guest doesn't send anything. Or I've heard from the upper layer team that the control/management plane may be in charge of the network recovery after migration so RARP is not a must. > Exactly what happened, we just did not think it through completely :) Thanks > > > -- > MST >
