On Tue, Sep 09, 2025 at 05:55:30PM +0200, Stefano Brivio wrote:
On Tue, 9 Sep 2025 12:10:45 +0200 Volker Diels-Grabsch
wrote: David Gibson wrote:
Looks good to me. It would be nice to also send an Neighbour Discovery request to accomplish the same thing for IPv6 only guests, but that could be a separate patch.
Good point! I'd prefer to do it in the same patch, as I'd also like fix another minor detail in this one.
Just for the sake of clarity: I had a look at RFC4861 and there are many types of Neighbour Discovery requests. For our purpose, I believe that we want to send a "Neighbor Solicitation Message" described in section 4.3:
https://datatracker.ietf.org/doc/html/rfc4861#section-4.3
Do you agree, or did you have something else in mind?
I was about to comment on this, but from the new patch you sent, I see you already figured out it's a Neighbour Solicitation and that we already have some bits of code for that. :)
Note that even with this patch, active TCP connections (and in some cases UDP flows) will be broken by a passt restart.
Indeed, that is unavoidable for a user-space tool opening TCP and UDP connections, I guess, unless "passt" itself is wrapped into another process or system tool that keeps those connections open. But let's not go into that.
Actually, it's not really unavoidable, in the sense that we recently added (see migrate.c, repair.c, passt-repair.c, and passt-repair(1)) support for migration of live TCP connections triggered by vhost-user commands:
Right, but doing this requires knowing in advance, support from qemu and a bunch of infrastructure. It's not going to work if you just kill and restart passt. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson