From: "Gonglei (Arei)" <arei.gonglei@huawei.com>
To: Jinpu Wang <jinpu.wang@ionos.com>
Cc: "Greg Sword" <gregsword0@gmail.com>,
"Peter Xu" <peterx@redhat.com>, "Yu Zhang" <yu.zhang@ionos.com>,
"Michael Galaxy" <mgalaxy@akamai.com>,
"Elmar Gerdes" <elmar.gerdes@ionos.com>,
zhengchuan <zhengchuan@huawei.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Yuval Shaia" <yuval.shaia.ml@gmail.com>,
"Kevin Wolf" <kwolf@redhat.com>,
"Prasanna Kumar Kalever" <prasanna.kalever@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Michael Roth" <michael.roth@amd.com>,
"Prasanna Kumar Kalever" <prasanna4324@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"devel@lists.libvirt.org" <devel@lists.libvirt.org>,
"Hanna Reitz" <hreitz@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Song Gao" <gaosong@loongson.cn>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
Pannengyuan <pannengyuan@huawei.com>,
Xiexiangyou <xiexiangyou@huawei.com>,
"Fabiano Rosas" <farosas@suse.de>,
"RDMA mailing list" <linux-rdma@vger.kernel.org>,
"shefty@nvidia.com" <shefty@nvidia.com>,
"Haris Iqbal" <haris.iqbal@ionos.com>
Subject: RE: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
Date: Wed, 29 May 2024 09:47:57 +0000 [thread overview]
Message-ID: <2665934438364f5e9e80ac4564cac2c3@huawei.com> (raw)
In-Reply-To: <CAMGffEna=8vNm89SkzRknLb7irTit0dBeciuC+_KMp+4U0PtQw@mail.gmail.com>
Hi,
> -----Original Message-----
> > >
> https://lore.kernel.org/qemu-devel/CAMGffEn-DKpMZ4tA71MJYdyemg0Zda
> > > > > > 15
> > > > > > > > wVAqk81vXtKzx-LfJQ@mail.gmail.com/
> > > > > > > >
> > > > > > > > Appreciate a lot for everyone helping on the testings.
> > > > > > > >
> > > > > > > > > InfiniBand controller: Mellanox Technologies MT27800
> > > > > > > > > Family [ConnectX-5]
> > > > > > > > >
> > > > > > > > > which doesn't meet our purpose. I can choose RDMA or TCP
> > > > > > > > > for VM migration. RDMA traffic is through InfiniBand and
> > > > > > > > > TCP through Ethernet on these two hosts. One is standby
> > > > > > > > > while the other
> > > is active.
> > > > > > > > >
> > > > > > > > > Now I'll try on a server with more recent Ethernet and
> > > > > > > > > InfiniBand network adapters. One of them has:
> > > > > > > > > BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller
> > > > > > > > > (rev
> > > > > > > > > 01)
> > > > > > > > >
> > > > > > > > > The comparison between RDMA and TCP on the same NIC
> > > > > > > > > could make more
> > > > > > > > sense.
> > > > > > > >
> > > > > > > > It looks to me NICs are powerful now, but again as I
> > > > > > > > mentioned I don't think it's a reason we need to deprecate
> > > > > > > > rdma, especially if QEMU's rdma migration has the chance
> > > > > > > > to be refactored
> > > using rsocket.
> > > > > > > >
> > > > > > > > Is there anyone who started looking into that direction?
> > > > > > > > Would it make sense we start some PoC now?
> > > > > > > >
> > > > > > >
> > > > > > > My team has finished the PoC refactoring which works well.
> > > > > > >
> > > > > > > Progress:
> > > > > > > 1. Implement io/channel-rdma.c, 2. Add unit test
> > > > > > > tests/unit/test-io-channel-rdma.c and verifying it is
> > > > > > > successful, 3. Remove the original code from migration/rdma.c, 4.
> > > > > > > Rewrite the rdma_start_outgoing_migration and
> > > > > > > rdma_start_incoming_migration logic, 5. Remove all rdma_xxx
> > > > > > > functions from migration/ram.c. (to prevent RDMA live
> > > > > > > migration from polluting the
> > > > > > core logic of live migration), 6. The soft-RoCE implemented
> > > > > > by software is used to test the RDMA live migration. It's successful.
> > > > > > >
> > > > > > > We will be submit the patchset later.
> > > > > >
> > > > > > That's great news, thank you!
> > > > > >
> > > > > > --
> > > > > > Peter Xu
> > > > >
> > > > > For rdma programming, the current mainstream implementation is
> > > > > to use
> > > rdma_cm to establish a connection, and then use verbs to transmit data.
> > > > >
> > > > > rdma_cm and ibverbs create two FDs respectively. The two FDs
> > > > > have different responsibilities. rdma_cm fd is used to notify
> > > > > connection establishment events, and verbs fd is used to notify
> > > > > new CQEs. When
> > > poll/epoll monitoring is directly performed on the rdma_cm fd, only
> > > a pollin event can be monitored, which means that an rdma_cm event
> > > occurs. When the verbs fd is directly polled/epolled, only the
> > > pollin event can be listened, which indicates that a new CQE is generated.
> > > > >
> > > > > Rsocket is a sub-module attached to the rdma_cm library and
> > > > > provides rdma calls that are completely similar to socket interfaces.
> > > > > However, this library returns only the rdma_cm fd for listening
> > > > > to link
> > > setup-related events and does not expose the verbs fd (readable and
> > > writable events for listening to data). Only the rpoll interface
> > > provided by the RSocket can be used to listen to related events.
> > > However, QEMU uses the ppoll interface to listen to the rdma_cm fd
> (gotten by raccept API).
> > > > > And cannot listen to the verbs fd event.
> I'm confused, the rs_poll_arm
> :https://github.com/linux-rdma/rdma-core/blob/master/librdmacm/rsocket.c#
> L3290
> For STREAM, rpoll setup fd for both cq fd and cm fd.
>
Right. But the question is QEMU do not use rpoll but gilb's ppoll. :(
Regards,
-Gonglei
next prev parent reply other threads:[~2024-05-29 9:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Zjj0xa-3KrFHTK0S@x1n>
[not found] ` <addaa8d094904315a466533763689ead@huawei.com>
[not found] ` <ZjpWmG2aUJLkYxJm@x1n>
[not found] ` <13ce4f9e-1e7c-24a9-0dc9-c40962979663@huawei.com>
[not found] ` <ZjzaIAMgUHV8zdNz@x1n>
[not found] ` <CAHEcVy48Mcup3d3FgYh_oPtV-M9CZBVr4G_9jyg2K+8Esi0WGA@mail.gmail.com>
[not found] ` <04769507-ac37-495d-a797-e05084d73e64@akamai.com>
[not found] ` <CAHEcVy4d7uJENZ1hRx2FBzbw22qN4Qm0TwtxvM5DLw3s81Zp_g@mail.gmail.com>
[not found] ` <Zk0c51D1Oo6NdIxR@x1n>
[not found] ` <2308a8b894244123b638038e40a33990@huawei.com>
[not found] ` <ZlX-Swq4Hi-0iHeh@x1n>
[not found] ` <7bf81ccee4bd4b0e81e3893ef43502a8@huawei.com>
2024-05-29 4:33 ` [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling Jinpu Wang
2024-05-29 6:05 ` Greg Sword
2024-05-29 7:04 ` Jinpu Wang
2024-05-29 8:30 ` Gonglei (Arei)
2024-05-29 9:17 ` Jinpu Wang
2024-05-29 9:34 ` Gonglei (Arei)
2024-05-29 9:47 ` Gonglei (Arei) [this message]
2024-05-29 11:13 ` Haris Iqbal
2024-05-30 18:23 ` Sean Hefty
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=2665934438364f5e9e80ac4564cac2c3@huawei.com \
--to=arei.gonglei@huawei.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=bleal@redhat.com \
--cc=cohuck@redhat.com \
--cc=devel@lists.libvirt.org \
--cc=eblake@redhat.com \
--cc=elmar.gerdes@ionos.com \
--cc=farosas@suse.de \
--cc=gaosong@loongson.cn \
--cc=gregsword0@gmail.com \
--cc=haris.iqbal@ionos.com \
--cc=hreitz@redhat.com \
--cc=jinpu.wang@ionos.com \
--cc=kwolf@redhat.com \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=marcandre.lureau@redhat.com \
--cc=mgalaxy@akamai.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=pannengyuan@huawei.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=prasanna.kalever@redhat.com \
--cc=prasanna4324@gmail.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shefty@nvidia.com \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=xiexiangyou@huawei.com \
--cc=yu.zhang@ionos.com \
--cc=yuval.shaia.ml@gmail.com \
--cc=zhengchuan@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox