Re: [PATCH v4 7/7] Update maintainer contact for migration multifd zero page checking acceleration.

[Peter Xu <peterx@redhat.com>]

On Fri, Mar 01, 2024 at 02:28:29AM +0000, Hao Xiang wrote:
> Add myself to maintain multifd zero page checking acceleration function.
> 
> Signed-off-by: Hao Xiang <hao.xiang@bytedance.com>
> ---
>  MAINTAINERS | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 65dfdc9677..b547918e4d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3414,6 +3414,11 @@ F: tests/migration/
>  F: util/userfaultfd.c
>  X: migration/rdma*
>  
> +Migration multifd zero page checking acceleration
> +M: Hao Xiang <hao.xiang@bytedance.com>
> +S: Maintained
> +F: migration/multifd-zero-page.c
> +

Firstly appreciate a lot for volunteering!

My fault to not have made it clear.  This file alone so far will need to be
closely related to the multifd core, so whoever maintains migration should
look after this.  It's also slightly weird to have a separate entry for a
file that is tens of LOC if it's already covered by another upper entry.

What I worry is about vendor/library specific parts that will be harder to
maintain, and migration maintainers (no matter who does the job in the
future) may not always cover those areas.  So I was expecting we could have
volunteers covering e.g. QAT / DSA / IAA accelerators.  Since all these
accelerators will all be part of Intel's new chips, there's also one way
that we have "Intel accelerators" section to cover vendor specific codes
and then cover all those areas no matter it's zero detect accelerator or HW
compressors.

I'd suggest we discuss this with Intel people to check out a solid plan
later when we start to merge HW/LIB specific codes.  For now I suggest we
can drop this patch and stick with the feature implementation, to see
whether it can catch the train for 9.0.  IMHO this is a good feature even
without HW accelerators (and I think it's close to ready), so I hope it can
still make it.

Thanks,

-- 
Peter Xu