On 09/01/23 7:37 pm, Daniel P. Berrangé wrote:
On Mon, Dec 26, 2022 at 05:33:25AM +0000, Het Gala wrote:
From: Author Het Gala <het.g...@nutanix.com>
Existing 'migrate' QAPI design enforces transport mechanism, ip address
of destination interface and corresponding port number in the form
of a unified string 'uri' parameter. This scheme does seem to have an issue
in it, i.e. double-level encoding of URIs.
The current patch maps existing QAPI design into a well-defined data
structure - 'MigrateChannel' only from the design perspective. Please note that
the existing 'uri' parameter is kept untouched for backward compatibility.
+##
+# @MigrateRdmaAddr:
+#
+# Since 8.0
+##
+{ 'struct': 'MigrateRdmaAddr',
+ 'data' : {'rdma-str': 'str' } }
Loooking at the RDMA code it takes the str, and treats it
as an IPv4 address:
addr = g_new(InetSocketAddress, 1);
if (!inet_parse(addr, host_port, NULL)) {
rdma->port = atoi(addr->port);
rdma->host = g_strdup(addr->host);
rdma->host_port = g_strdup(host_port);
}
so we really ought to accept an InetSocketAddress struct
directly
{ 'struct': 'MigrateRdmaAddr',
'data' : {'rdma-str': 'InetSocketAddress' } }
Hi Daniel. I was going through the rdma code, and I think we also need
'host_port' for rdma_return_path context
https://github.com/qemu/qemu/commit/44bcfd45e9806c78d9d526d69b0590227d215a78.
I dont have much understanding but If you have any suggestion or a
workaround for this, please suggest :)
+
+##
+# @MigrateAddress:
+#
+# The options available for communication transport mechanisms for migration
+#
+# Since 8.0
+##
With regards,
Daniel
Regards,
Het Gala
