qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: Leon Romanovsky <leon@kernel.org>, Michael Galaxy <mgalaxy@akamai.com>
Cc: Yu Zhang <yu.zhang@ionos.com>, Sean Hefty <shefty@nvidia.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"elmar.gerdes@ionos.com" <elmar.gerdes@ionos.com>,
	zhengchuan <zhengchuan@huawei.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	Xiexiangyou <xiexiangyou@huawei.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"lixiao (H)" <lixiao91@huawei.com>,
	"jinpu.wang@ionos.com" <jinpu.wang@ionos.com>,
	Wangjialin <wangjialin23@huawei.com>
Subject: Re: [PATCH 0/6] refactor RDMA live migration based on rsocket API
Date: Tue, 8 Oct 2024 17:31:37 +0800	[thread overview]
Message-ID: <3cecfd89-b6a6-47cc-8361-de6be943cf80@linux.dev> (raw)
In-Reply-To: <20241007181513.GC25819@unreal>

在 2024/10/8 2:15, Leon Romanovsky 写道:
> On Mon, Oct 07, 2024 at 08:45:07AM -0500, Michael Galaxy wrote:
>> Hi,
>>
>> On 10/7/24 03:47, Yu Zhang wrote:
>>> !-------------------------------------------------------------------|
>>>     This Message Is From an External Sender
>>>     This message came from outside your organization.
>>> |-------------------------------------------------------------------!
>>>
>>> Sure, as we talked at the KVM Forum, a possible approach is to set up
>>> two VMs on a physical host, configure the SoftRoCE, and run the
>>> migration test in two nested VMs to ensure that the migration data
>>> traffic goes through the emulated RDMA hardware. I will continue with
>>> this and let you know.
>>>
>> Acknowledged. Do share if you have any problems with it, like if it has
>> compatibility issues
>> or if we need a different solution. We're open to change.
>>
>> I'm not familiar with the "current state" of this or how well it would even
>> work.
> 
> Any compatibility issue between versions of RXE (SoftRoCE) or between
> RXE and real devices is a bug in RXE, which should be fixed.
> 
> RXE is expected to be compatible with rest RoCE devices, both virtual
> and physical.

 From my tests, about physical RoCE devices, for example, Nvidia MLX5 
and intel E810 (iRDMA), if RDMA feature is disabled on those devices. 
RXE can work well with them.

About Virtual devices, most virtual devices can work well with RXE, for 
example,bonding, veth. I have done a lot of tests with them.

If some virtual devices can not work well with RXE, please share the 
error messages in RDMA maillist.

Zhu Yanjun

> 
> Thanks
> 
>>
>> - Michael
>>
>>
>>> On Fri, Oct 4, 2024 at 4:06 PM Michael Galaxy <mgalaxy@akamai.com> wrote:
>>>>
>>>> On 10/3/24 16:43, Peter Xu wrote:
>>>>> !-------------------------------------------------------------------|
>>>>>      This Message Is From an External Sender
>>>>>      This message came from outside your organization.
>>>>> |-------------------------------------------------------------------!
>>>>>
>>>>> On Thu, Oct 03, 2024 at 04:26:27PM -0500, Michael Galaxy wrote:
>>>>>> What about the testing solution that I mentioned?
>>>>>>
>>>>>> Does that satisfy your concerns? Or is there still a gap here that needs to
>>>>>> be met?
>>>>> I think such testing framework would be helpful, especially if we can kick
>>>>> it off in CI when preparing pull requests, then we can make sure nothing
>>>>> will break RDMA easily.
>>>>>
>>>>> Meanwhile, we still need people committed to this and actively maintain it,
>>>>> who knows the rdma code well.
>>>>>
>>>>> Thanks,
>>>>>
>>>> OK, so comments from Yu Zhang and Gonglei? Can we work up a CI test
>>>> along these lines that would ensure that future RDMA breakages are
>>>> detected more easily?
>>>>
>>>> What do you think?
>>>>
>>>> - Michael
>>>>
>>



  reply	other threads:[~2024-10-08 13:04 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 12:14 [PATCH 0/6] refactor RDMA live migration based on rsocket API Gonglei via
2024-06-04 12:14 ` [PATCH 1/6] migration: remove RDMA live migration temporarily Gonglei via
2024-06-04 14:01   ` David Hildenbrand
2024-06-05 10:02     ` Gonglei (Arei) via
2024-06-10 11:45   ` Markus Armbruster
2024-06-04 12:14 ` [PATCH 2/6] io: add QIOChannelRDMA class Gonglei via
2024-06-10  6:54   ` Jinpu Wang
2024-06-04 12:14 ` [PATCH 3/6] io/channel-rdma: support working in coroutine Gonglei via
2024-06-06 13:34   ` Haris Iqbal
2024-06-07  8:45     ` Gonglei (Arei) via
2024-06-07 10:01       ` Haris Iqbal
2024-06-07  9:04   ` Daniel P. Berrangé
2024-06-07  9:28     ` Gonglei (Arei) via
2024-06-04 12:14 ` [PATCH 4/6] tests/unit: add test-io-channel-rdma.c Gonglei via
2024-06-04 12:14 ` [PATCH 5/6] migration: introduce new RDMA live migration Gonglei via
2024-06-04 12:14 ` [PATCH 6/6] migration/rdma: support multifd for RDMA migration Gonglei via
2024-06-04 19:32 ` [PATCH 0/6] refactor RDMA live migration based on rsocket API Peter Xu
2024-06-05 10:09   ` Gonglei (Arei) via
2024-06-05 14:18     ` Peter Xu
2024-06-07  8:49       ` Gonglei (Arei) via
2024-06-10 16:35         ` Peter Xu
2024-06-07 10:06   ` Daniel P. Berrangé
2024-06-05  7:57 ` Michael S. Tsirkin
2024-06-05 10:00   ` Gonglei (Arei) via
2024-06-05 10:23     ` Michael S. Tsirkin
2024-06-06 11:31     ` Leon Romanovsky
2024-06-07  1:04       ` Zhijian Li (Fujitsu) via
2024-06-07 16:24     ` Yu Zhang
2024-06-07  5:53 ` Jinpu Wang
2024-06-07  8:28   ` Gonglei (Arei) via
2024-06-10 16:31     ` Peter Xu
2024-08-27 20:15 ` Peter Xu
2024-08-27 20:57   ` Michael S. Tsirkin
2024-09-22 19:29     ` Michael Galaxy
2024-09-23  1:04       ` Gonglei (Arei) via
2024-09-25 15:08         ` Peter Xu
2024-09-27 21:45           ` Sean Hefty
2024-09-28 17:52             ` Michael Galaxy
2024-09-29 18:14               ` Michael S. Tsirkin
2024-09-29 20:26                 ` Michael Galaxy
2024-09-29 22:26                   ` Michael S. Tsirkin
2024-09-30 15:00                     ` Michael Galaxy
2024-09-30 15:31                       ` Yu Zhang
2024-09-30 18:16               ` Peter Xu
2024-09-30 19:20                 ` Sean Hefty
2024-09-30 19:47                   ` Peter Xu
2024-10-03 21:26                     ` Michael Galaxy
2024-10-03 21:43                       ` Peter Xu
2024-10-04 14:04                         ` Michael Galaxy
2024-10-07  8:47                           ` Yu Zhang
2024-10-07 13:45                             ` Michael Galaxy
2024-10-07 18:15                               ` Leon Romanovsky
2024-10-08  9:31                                 ` Zhu Yanjun [this message]
2024-10-23 13:42                               ` Michael Galaxy
2024-09-27 20:34         ` Michael Galaxy

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=3cecfd89-b6a6-47cc-8361-de6be943cf80@linux.dev \
    --to=yanjun.zhu@linux.dev \
    --cc=arei.gonglei@huawei.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=elmar.gerdes@ionos.com \
    --cc=jinpu.wang@ionos.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lixiao91@huawei.com \
    --cc=lizhijian@fujitsu.com \
    --cc=mgalaxy@akamai.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shefty@nvidia.com \
    --cc=wangjialin23@huawei.com \
    --cc=xiexiangyou@huawei.com \
    --cc=yu.zhang@ionos.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;
as well as URLs for NNTP newsgroup(s).