[PATCH 0/5] RFC: Assorted migration improvements
Here are some things that I think improve the draft migration logic. This is based on both the draft migration series (v2) and my epoll_del() series. Feel free to fold into the existing patches if that seems sensible. David Gibson (5): migrate: Add passt-repair to .gitignore migrate: vu_migrate_{source,target}() aren't actually vu speciic migrate: Move repair_sock_init() to vu_init() migrate: Make more handling common rather than vhost-user specific migrate: Don't handle the migration channel through epoll .gitignore | 1 + epoll_type.h | 2 - migrate.c | 148 +++++++++++++++++++++++++++++++++++++++++++++++---- migrate.h | 12 ++--- passt.c | 6 +-- passt.h | 8 +++ tap.c | 3 -- vhost_user.c | 58 +++----------------- virtio.h | 4 -- vu_common.c | 89 ------------------------------- vu_common.h | 2 +- 11 files changed, 162 insertions(+), 171 deletions(-) -- 2.48.1
Like our other executable targets.
Signed-off-by: David Gibson
vu_migrate_source() and vu_migrate_target() don't directly rely on anything
vhost-user specific - it's just that they'll only be called for vhost-user
so far. They are suitable as general top-level dispatchers for
migration. Move them to migrate.c, rename to migrate_{source,target}() and
make the lower-level functions they call local to migrate.c.
Signed-off-by: David Gibson
Currently we call repair_sock_init() immediately before
tap_sock_unix_init(). However, this means it will be skipped if the
vhost-user control fd is passed with --fd instead of being created at a
specific path. We still need the repair socket in that case.
Move it, instead, to vu_init(), which has the added advantage of moving
all migration related one-time init to the same place.
Signed-off-by: David Gibson
On Thu, 30 Jan 2025 19:33:28 +1100
David Gibson
Currently we call repair_sock_init() immediately before tap_sock_unix_init(). However, this means it will be skipped if the vhost-user control fd is passed with --fd instead of being created at a specific path.
That's intended, because we might not have a path in that case. See conf_open_files(). I know it's not perfectly consistent, but it's practical at the moment. The alternative opens up complicated questions such as: should we have a --fd-repair option? What should be the default path if only --fd is given? This is really unnecessary right now. -- Stefano
On Tue, Feb 04, 2025 at 01:42:31AM +0100, Stefano Brivio wrote:
On Thu, 30 Jan 2025 19:33:28 +1100 David Gibson
wrote: Currently we call repair_sock_init() immediately before tap_sock_unix_init(). However, this means it will be skipped if the vhost-user control fd is passed with --fd instead of being created at a specific path.
That's intended, because we might not have a path in that case. See conf_open_files().
Hm, good point. We should probably make it conditional on actually having a path in that case. If --fd and --repair-path are used together, that should work, and at the moment it won't.
I know it's not perfectly consistent, but it's practical at the moment.
The alternative opens up complicated questions such as: should we have a --fd-repair option? What should be the default path if only --fd is given? This is really unnecessary right now.
I don't think we can have an --fd-repair, since part of the security model for passt-repair is that it connects to passt, not the other way around. We could, however, require --repair path if you want to use migration with --fd. -- 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
A lot of the migration logic in vhost_user.c and vu_common.c isn't really
specific to vhost-user, but matches the overall structure of migration.
This applies to vu_migrate() and to the parts of of
vu_set_device_state_fd_exec() which aren't related to parsing the specific
vhost-user control request.
Move this logic to migrate.c, with matching renames.
Signed-off-by: David Gibson
Currently, once a migration device state fd is assigned, we wait for
EPOLLIN or EPOLLOUT events on it to actually perform the migration. Change
it so that once a migration is requested it we complete it synchronously
at the end of the current epoll cycle. This has several advantages:
1. It makes it clear that everything about the migration must be dealt
with at once, not split between multiple epoll events on the channel
2. It ensures the migration always takes place between epoll cycles,
rather than, for example, between handling TCP events and their
deferred handling in post_handler().
3. It reduces code setting up the epoll watch on the fd.
Signed-off-by: David Gibson
On Thu, 30 Jan 2025 19:33:30 +1100
David Gibson
--- a/migrate.c +++ b/migrate.c @@ -327,26 +327,6 @@ static int migrate_target(struct ctx *c, int fd) return rc; }
-/** - * set_migration_watch() - Add the migration file descriptor to epoll - * @c: Execution context - * @fd: File descriptor to add - * @target: Are we the target of the migration? - */ -static void set_migration_watch(const struct ctx *c, int fd, bool target) -{ - union epoll_ref ref = { - .type = EPOLL_TYPE_DEVICE_STATE, - .fd = fd, - }; - struct epoll_event ev = { 0 }; - - ev.data.u64 = ref.u64; - ev.events = target ? EPOLLIN : EPOLLOUT; - - epoll_ctl(c->epollfd, EPOLL_CTL_ADD, ref.fd, &ev);
This change should have dropped: epoll_del(c, c->device_state_fd); from migrate_close(). -- Stefano
On Fri, Jan 31, 2025 at 06:37:09AM +0100, Stefano Brivio wrote:
On Thu, 30 Jan 2025 19:33:30 +1100 David Gibson
wrote: --- a/migrate.c +++ b/migrate.c @@ -327,26 +327,6 @@ static int migrate_target(struct ctx *c, int fd) return rc; }
-/** - * set_migration_watch() - Add the migration file descriptor to epoll - * @c: Execution context - * @fd: File descriptor to add - * @target: Are we the target of the migration? - */ -static void set_migration_watch(const struct ctx *c, int fd, bool target) -{ - union epoll_ref ref = { - .type = EPOLL_TYPE_DEVICE_STATE, - .fd = fd, - }; - struct epoll_event ev = { 0 }; - - ev.data.u64 = ref.u64; - ev.events = target ? EPOLLIN : EPOLLOUT; - - epoll_ctl(c->epollfd, EPOLL_CTL_ADD, ref.fd, &ev);
This change should have dropped:
epoll_del(c, c->device_state_fd);
from migrate_close().
Oops, yes. I've fixed it in my local version, in case I need to rebase before you've folded it all in. -- 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
On Thu, 30 Jan 2025 19:33:25 +1100
David Gibson
Here are some things that I think improve the draft migration logic. This is based on both the draft migration series (v2) and my epoll_del() series.
Feel free to fold into the existing patches if that seems sensible.
Sure, let me post a v3 with these included. Do you prefer to keep all the patches as they are or should I merge 2/5 and 3/5 with the patches in my current series? -- Stefano
On Thu, Jan 30, 2025 at 09:46:19AM +0100, Stefano Brivio wrote:
On Thu, 30 Jan 2025 19:33:25 +1100 David Gibson
wrote: Here are some things that I think improve the draft migration logic. This is based on both the draft migration series (v2) and my epoll_del() series.
Feel free to fold into the existing patches if that seems sensible.
Sure, let me post a v3 with these included.
Do you prefer to keep all the patches as they are or should I merge 2/5 and 3/5 with the patches in my current series?
Whichever you prefer. And 1/5 probably _should_ be folded in. -- 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
On Thu, 30 Jan 2025 19:55:11 +1100
David Gibson
On Thu, Jan 30, 2025 at 09:46:19AM +0100, Stefano Brivio wrote:
On Thu, 30 Jan 2025 19:33:25 +1100 David Gibson
wrote: Here are some things that I think improve the draft migration logic. This is based on both the draft migration series (v2) and my epoll_del() series.
Feel free to fold into the existing patches if that seems sensible.
Sure, let me post a v3 with these included.
Do you prefer to keep all the patches as they are or should I merge 2/5 and 3/5 with the patches in my current series?
Whichever you prefer. And 1/5 probably _should_ be folded in.
So, yeah, I have a merged series ready, but I'm trying to solve the concrete problem I'm facing before posting it. Actually, merging clean-ups with no _intended_ impact on functionality, while trying to do this, isn't terribly helpful, but it didn't take that long. -- Stefano
On Fri, Jan 31, 2025 at 06:46:25AM +0100, Stefano Brivio wrote:
On Thu, 30 Jan 2025 19:55:11 +1100 David Gibson
wrote: On Thu, Jan 30, 2025 at 09:46:19AM +0100, Stefano Brivio wrote:
On Thu, 30 Jan 2025 19:33:25 +1100 David Gibson
wrote: Here are some things that I think improve the draft migration logic. This is based on both the draft migration series (v2) and my epoll_del() series.
Feel free to fold into the existing patches if that seems sensible.
Sure, let me post a v3 with these included.
Do you prefer to keep all the patches as they are or should I merge 2/5 and 3/5 with the patches in my current series?
Whichever you prefer. And 1/5 probably _should_ be folded in.
So, yeah, I have a merged series ready, but I'm trying to solve the concrete problem I'm facing before posting it.
Actually, merging clean-ups with no _intended_ impact on functionality, while trying to do this, isn't terribly helpful, but it didn't take that long.
So, the cleanups aren't purely cleanups for the sake of cleanups: they're things I think I need in preparation for the more compact flow table representation stuff. -- 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
participants (2)
-
David Gibson
-
Stefano Brivio