Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

Hi Zhijian,

On 29/3/24 02:53, Zhijian Li (Fujitsu) wrote:
> 
> 
> On 28/03/2024 23:01, Peter Xu wrote:
>> On Thu, Mar 28, 2024 at 11:18:04AM -0300, Fabiano Rosas wrote:
>>> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
>>>
>>>> The whole RDMA subsystem was deprecated in commit e9a54265f5
>>>> ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem")
>>>> released in v8.2.
>>>>
>>>> Remove:
>>>>    - RDMA handling from migration
>>>>    - dependencies on libibumad, libibverbs and librdmacm
>>>>
>>>> Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
>>>> in old migration streams.
>>>>
>>>> Cc: Peter Xu <peterx@redhat.com>
>>>> Cc: Li Zhijian <lizhijian@fujitsu.com>
>>>> Acked-by: Fabiano Rosas <farosas@suse.de>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>>
>>> Just to be clear, because people raised the point in the last version,
>>> the first link in the deprecation commit links to a thread comprising
>>> entirely of rdma migration patches. I don't see any ambiguity on whether
>>> the deprecation was intended to include migration. There's even an ack
>>> from Juan.
>>
>> Yes I remember that's the plan.
>>
>>>
>>> So on the basis of not reverting the previous maintainer's decision, my
>>> Ack stands here.
>>>
>>> We also had pretty obvious bugs ([1], [2]) in the past that would have
>>> been caught if we had any kind of testing for the feature, so I can't
>>> even say this thing works currently.
>>>
>>> @Peter Xu, @Li Zhijian, what are your thoughts on this?
>>
>> Generally I definitely agree with such a removal sooner or later, as that's
>> how deprecation works, and even after Juan's left I'm not aware of any
>> other new RDMA users.  Personally, I'd slightly prefer postponing it one
>> more release which might help a bit of our downstream maintenance, however
>> I assume that's not a blocker either, as I think we can also manage it.
>>
>> IMHO it's more important to know whether there are still users and whether
>> they would still like to see it around. That's also one thing I notice that
>> e9a54265f533f didn't yet get acks from RDMA users that we are aware, even
>> if they're rare. According to [2] it could be that such user may only rely
>> on the release versions of QEMU when it broke things.
>>
>> So I'm copying Yu too (while Zhijian is already in the loop), just in case
>> someone would like to stand up and speak.
> 
> 
> I admit RDMA migration was lack of testing(unit/CI test), which led to the a few
> obvious bugs being noticed too late.
> However I was a bit surprised when I saw the removal of the RDMA migration. I wasn't
> aware that this feature has not been marked as deprecated(at least there is no
> prompt to end-user).
> 
> 
>> IMHO it's more important to know whether there are still users and whether
>> they would still like to see it around.
> 
> Agree.
> I didn't immediately express my opinion in V1 because I'm also consulting our
> customers for this feature in the future.
> 
> Personally, I agree with Perter's idea that "I'd slightly prefer postponing it one
> more release which might help a bit of our downstream maintenance"

Do you mind posting a deprecation patch to clarify the situation?

Thanks,

Phil.

> 
> Thanks
> Zhijian
> 
>>
>> Thanks,
>>
>>>
>>> 1- https://lore.kernel.org/r/20230920090412.726725-1-lizhijian@fujitsu.com
>>> 2- https://lore.kernel.org/r/CAHEcVy7HXSwn4Ow_Kog+Q+TN6f_kMeiCHevz1qGM-fbxBPp1hQ@mail.gmail.com
>>>