[v3,5/5] vhost_user: Increase number of memory regions

Message ID 20251104042142.2787631-6-pravin.bathija@dell.com (mailing list archive)
State Superseded
Delegated to: Maxime Coquelin
Headers
Series Support add/remove memory region & get-max-slots |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-mellanox-Functional success Functional Testing PASS
ci/iol-marvell-Functional success Functional Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/intel-Functional success Functional PASS
ci/iol-compile-amd64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/github-robot: build success github build: passed
ci/github-robot-post success github post: success
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/aws-unit-testing success Unit Testing PASS
ci/intel-Testing success Testing PASS

Commit Message

Bathija, Pravin Nov. 4, 2025, 4:21 a.m. UTC
In this patch the number of memory regions are increased from
8 to 128. When a vhost-user front-end such as qemu or libblkio
queries the back-end such as dpdk with the message, get max number
of memory slots, the back-end replies with this number 128 instead
of the previously defined 8. The back-end also allocates that many
slots in the memory table where regions are added/removed as
requested by the vhost-user front-end. This also helps the vhost-
user front-end to limit the number of memory regions when sending
the set mem table message ar adding memory regions.

Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
---
 lib/vhost/vhost_user.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

fengchengwen Nov. 4, 2025, 8:12 a.m. UTC | #1
On 11/4/2025 12:21 PM, Pravin M Bathija wrote:
> In this patch the number of memory regions are increased from
> 8 to 128. When a vhost-user front-end such as qemu or libblkio
> queries the back-end such as dpdk with the message, get max number
> of memory slots, the back-end replies with this number 128 instead
> of the previously defined 8. The back-end also allocates that many
> slots in the memory table where regions are added/removed as
> requested by the vhost-user front-end. This also helps the vhost-
> user front-end to limit the number of memory regions when sending
> the set mem table message ar adding memory regions.
> 
> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> ---
>  lib/vhost/vhost_user.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
> index 5a0e747b58..c6ad5b76d6 100644
> --- a/lib/vhost/vhost_user.h
> +++ b/lib/vhost/vhost_user.h
> @@ -11,7 +11,7 @@
>  
>  /* refer to hw/virtio/vhost-user.c */
>  
> -#define VHOST_MEMORY_MAX_NREGIONS 8
> +#define VHOST_MEMORY_MAX_NREGIONS 128

The address translation may increase a lot if the real region is 128.
Maybe we should add another patch to optimize it.

>  
>  #define VHOST_USER_NET_SUPPORTED_FEATURES \
>  	(VIRTIO_NET_SUPPORTED_FEATURES | \
  
Bathija, Pravin Nov. 11, 2025, 11:34 a.m. UTC | #2
Responses inline.


Internal Use - Confidential
> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Tuesday, November 4, 2025 12:12 AM
> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
> Cc: pravin.m.bathija.dev@gmail.com
> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory regions
>
>
> [EXTERNAL EMAIL]
>
> On 11/4/2025 12:21 PM, Pravin M Bathija wrote:
> > In this patch the number of memory regions are increased from
> > 8 to 128. When a vhost-user front-end such as qemu or libblkio queries
> > the back-end such as dpdk with the message, get max number of memory
> > slots, the back-end replies with this number 128 instead of the
> > previously defined 8. The back-end also allocates that many slots in
> > the memory table where regions are added/removed as requested by the
> > vhost-user front-end. This also helps the vhost- user front-end to
> > limit the number of memory regions when sending the set mem table
> > message ar adding memory regions.
> >
> > Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> > ---
> >  lib/vhost/vhost_user.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h index
> > 5a0e747b58..c6ad5b76d6 100644
> > --- a/lib/vhost/vhost_user.h
> > +++ b/lib/vhost/vhost_user.h
> > @@ -11,7 +11,7 @@
> >
> >  /* refer to hw/virtio/vhost-user.c */
> >
> > -#define VHOST_MEMORY_MAX_NREGIONS 8
> > +#define VHOST_MEMORY_MAX_NREGIONS 128
>
> The address translation may increase a lot if the real region is 128.
> Maybe we should add another patch to optimize it.

Could you please share more thoughts on this ?  Are you concerned about the number of addresses and translation table bloat ? What optimization are you suggesting ?

>
> >
> >  #define VHOST_USER_NET_SUPPORTED_FEATURES \
> >     (VIRTIO_NET_SUPPORTED_FEATURES | \
  
fengchengwen Nov. 12, 2025, 1:26 a.m. UTC | #3
On 11/11/2025 7:34 PM, Bathija, Pravin wrote:
> Responses inline.
> 
> 
> Internal Use - Confidential
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Tuesday, November 4, 2025 12:12 AM
>> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
>> Cc: pravin.m.bathija.dev@gmail.com
>> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory regions
>>
>>
>> [EXTERNAL EMAIL]
>>
>> On 11/4/2025 12:21 PM, Pravin M Bathija wrote:
>>> In this patch the number of memory regions are increased from
>>> 8 to 128. When a vhost-user front-end such as qemu or libblkio queries
>>> the back-end such as dpdk with the message, get max number of memory
>>> slots, the back-end replies with this number 128 instead of the
>>> previously defined 8. The back-end also allocates that many slots in
>>> the memory table where regions are added/removed as requested by the
>>> vhost-user front-end. This also helps the vhost- user front-end to
>>> limit the number of memory regions when sending the set mem table
>>> message ar adding memory regions.
>>>
>>> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
>>> ---
>>>  lib/vhost/vhost_user.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h index
>>> 5a0e747b58..c6ad5b76d6 100644
>>> --- a/lib/vhost/vhost_user.h
>>> +++ b/lib/vhost/vhost_user.h
>>> @@ -11,7 +11,7 @@
>>>
>>>  /* refer to hw/virtio/vhost-user.c */
>>>
>>> -#define VHOST_MEMORY_MAX_NREGIONS 8
>>> +#define VHOST_MEMORY_MAX_NREGIONS 128
>>
>> The address translation may increase a lot if the real region is 128.
>> Maybe we should add another patch to optimize it.
> 
> Could you please share more thoughts on this ?  Are you concerned about the number of addresses and translation table bloat ? What optimization are you suggesting ?

Because each memory region is independent and does not overlap, maybe
we could use binary search to optimize it.

> 
>>
>>>
>>>  #define VHOST_USER_NET_SUPPORTED_FEATURES \
>>>     (VIRTIO_NET_SUPPORTED_FEATURES | \
> 
>
  
Bathija, Pravin Nov. 13, 2025, 2:13 a.m. UTC | #4
Answers inline


Internal Use - Confidential
> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Tuesday, November 11, 2025 5:26 PM
> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
> Cc: pravin.m.bathija.dev@gmail.com
> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory regions
>
>
> [EXTERNAL EMAIL]
>
> On 11/11/2025 7:34 PM, Bathija, Pravin wrote:
> > Responses inline.
> >
> >
> > Internal Use - Confidential
> >> -----Original Message-----
> >> From: fengchengwen <fengchengwen@huawei.com>
> >> Sent: Tuesday, November 4, 2025 12:12 AM
> >> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
> >> Cc: pravin.m.bathija.dev@gmail.com
> >> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory
> >> regions
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> On 11/4/2025 12:21 PM, Pravin M Bathija wrote:
> >>> In this patch the number of memory regions are increased from
> >>> 8 to 128. When a vhost-user front-end such as qemu or libblkio
> >>> queries the back-end such as dpdk with the message, get max number
> >>> of memory slots, the back-end replies with this number 128 instead
> >>> of the previously defined 8. The back-end also allocates that many
> >>> slots in the memory table where regions are added/removed as
> >>> requested by the vhost-user front-end. This also helps the vhost-
> >>> user front-end to limit the number of memory regions when sending
> >>> the set mem table message ar adding memory regions.
> >>>
> >>> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> >>> ---
> >>>  lib/vhost/vhost_user.h | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h index
> >>> 5a0e747b58..c6ad5b76d6 100644
> >>> --- a/lib/vhost/vhost_user.h
> >>> +++ b/lib/vhost/vhost_user.h
> >>> @@ -11,7 +11,7 @@
> >>>
> >>>  /* refer to hw/virtio/vhost-user.c */
> >>>
> >>> -#define VHOST_MEMORY_MAX_NREGIONS 8
> >>> +#define VHOST_MEMORY_MAX_NREGIONS 128
> >>
> >> The address translation may increase a lot if the real region is 128.
> >> Maybe we should add another patch to optimize it.
> >
> > Could you please share more thoughts on this ?  Are you concerned about
> the number of addresses and translation table bloat ? What optimization are
> you suggesting ?
>
> Because each memory region is independent and does not overlap, maybe we
> could use binary search to optimize it.

From what I gather, both of your latest comments, for patches 4 and 5 are related to performance impact because of 128 memory regions. My thoughts on this are, I will work on an algorithm to optimize as you suggested. Meanwhile we could approve patches 1-4. The rest of the implementation does not need 128 memory regions. The existing 8 regions are fine. I put in this change as I felt it makes the system scale more and was also suggested by Maxime. I think patches 1-4 stand by themselves and have been thoroughly tested. Please let me know your thoughts on this.

>
> >
> >>
> >>>
> >>>  #define VHOST_USER_NET_SUPPORTED_FEATURES \
> >>>     (VIRTIO_NET_SUPPORTED_FEATURES | \
> >
> >
  
fengchengwen Nov. 13, 2025, 7:23 a.m. UTC | #5
On 11/13/2025 10:13 AM, Bathija, Pravin wrote:
> Answers inline
> 
> 
> Internal Use - Confidential
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Tuesday, November 11, 2025 5:26 PM
>> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
>> Cc: pravin.m.bathija.dev@gmail.com
>> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory regions
>>
>>
>> [EXTERNAL EMAIL]
>>
>> On 11/11/2025 7:34 PM, Bathija, Pravin wrote:
>>> Responses inline.
>>>
>>>
>>> Internal Use - Confidential
>>>> -----Original Message-----
>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>> Sent: Tuesday, November 4, 2025 12:12 AM
>>>> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
>>>> Cc: pravin.m.bathija.dev@gmail.com
>>>> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory
>>>> regions
>>>>
>>>>
>>>> [EXTERNAL EMAIL]
>>>>
>>>> On 11/4/2025 12:21 PM, Pravin M Bathija wrote:
>>>>> In this patch the number of memory regions are increased from
>>>>> 8 to 128. When a vhost-user front-end such as qemu or libblkio
>>>>> queries the back-end such as dpdk with the message, get max number
>>>>> of memory slots, the back-end replies with this number 128 instead
>>>>> of the previously defined 8. The back-end also allocates that many
>>>>> slots in the memory table where regions are added/removed as
>>>>> requested by the vhost-user front-end. This also helps the vhost-
>>>>> user front-end to limit the number of memory regions when sending
>>>>> the set mem table message ar adding memory regions.
>>>>>
>>>>> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
>>>>> ---
>>>>>  lib/vhost/vhost_user.h | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h index
>>>>> 5a0e747b58..c6ad5b76d6 100644
>>>>> --- a/lib/vhost/vhost_user.h
>>>>> +++ b/lib/vhost/vhost_user.h
>>>>> @@ -11,7 +11,7 @@
>>>>>
>>>>>  /* refer to hw/virtio/vhost-user.c */
>>>>>
>>>>> -#define VHOST_MEMORY_MAX_NREGIONS 8
>>>>> +#define VHOST_MEMORY_MAX_NREGIONS 128
>>>>
>>>> The address translation may increase a lot if the real region is 128.
>>>> Maybe we should add another patch to optimize it.
>>>
>>> Could you please share more thoughts on this ?  Are you concerned about
>> the number of addresses and translation table bloat ? What optimization are
>> you suggesting ?
>>
>> Because each memory region is independent and does not overlap, maybe we
>> could use binary search to optimize it.
> 
> From what I gather, both of your latest comments, for patches 4 and 5 are related to performance impact because of 128 memory regions. My thoughts on this are, I will work on an algorithm to optimize as you suggested. Meanwhile we could approve patches 1-4. The rest of the implementation does not need 128 memory regions. The existing 8 regions are fine. I put in this change as I felt it makes the system scale more and was also suggested by Maxime. I think patches 1-4 stand by themselves and have been thoroughly tested. Please let me know your thoughts on this.

I am OK for this.

> 
>>
>>>
>>>>
>>>>>
>>>>>  #define VHOST_USER_NET_SUPPORTED_FEATURES \
>>>>>     (VIRTIO_NET_SUPPORTED_FEATURES | \
>>>
>>>
> 
>
  
Bathija, Pravin Nov. 13, 2025, 12:47 p.m. UTC | #6
Responses inline.


Internal Use - Confidential
> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Wednesday, November 12, 2025 11:23 PM
> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
> Cc: pravin.m.bathija.dev@gmail.com
> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory regions
>
>
> [EXTERNAL EMAIL]
>
> On 11/13/2025 10:13 AM, Bathija, Pravin wrote:
> > Answers inline
> >
> >
> > Internal Use - Confidential
> >> -----Original Message-----
> >> From: fengchengwen <fengchengwen@huawei.com>
> >> Sent: Tuesday, November 11, 2025 5:26 PM
> >> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
> >> Cc: pravin.m.bathija.dev@gmail.com
> >> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory
> >> regions
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> On 11/11/2025 7:34 PM, Bathija, Pravin wrote:
> >>> Responses inline.
> >>>
> >>>
> >>> Internal Use - Confidential
> >>>> -----Original Message-----
> >>>> From: fengchengwen <fengchengwen@huawei.com>
> >>>> Sent: Tuesday, November 4, 2025 12:12 AM
> >>>> To: Bathija, Pravin <Pravin.Bathija@dell.com>; dev@dpdk.org
> >>>> Cc: pravin.m.bathija.dev@gmail.com
> >>>> Subject: Re: [PATCH v3 5/5] vhost_user: Increase number of memory
> >>>> regions
> >>>>
> >>>>
> >>>> [EXTERNAL EMAIL]
> >>>>
> >>>> On 11/4/2025 12:21 PM, Pravin M Bathija wrote:
> >>>>> In this patch the number of memory regions are increased from
> >>>>> 8 to 128. When a vhost-user front-end such as qemu or libblkio
> >>>>> queries the back-end such as dpdk with the message, get max number
> >>>>> of memory slots, the back-end replies with this number 128 instead
> >>>>> of the previously defined 8. The back-end also allocates that many
> >>>>> slots in the memory table where regions are added/removed as
> >>>>> requested by the vhost-user front-end. This also helps the vhost-
> >>>>> user front-end to limit the number of memory regions when sending
> >>>>> the set mem table message ar adding memory regions.
> >>>>>
> >>>>> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> >>>>> ---
> >>>>>  lib/vhost/vhost_user.h | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h index
> >>>>> 5a0e747b58..c6ad5b76d6 100644
> >>>>> --- a/lib/vhost/vhost_user.h
> >>>>> +++ b/lib/vhost/vhost_user.h
> >>>>> @@ -11,7 +11,7 @@
> >>>>>
> >>>>>  /* refer to hw/virtio/vhost-user.c */
> >>>>>
> >>>>> -#define VHOST_MEMORY_MAX_NREGIONS 8
> >>>>> +#define VHOST_MEMORY_MAX_NREGIONS 128
> >>>>
> >>>> The address translation may increase a lot if the real region is 128.
> >>>> Maybe we should add another patch to optimize it.
> >>>
> >>> Could you please share more thoughts on this ?  Are you concerned
> >>> about
> >> the number of addresses and translation table bloat ? What
> >> optimization are you suggesting ?
> >>
> >> Because each memory region is independent and does not overlap, maybe
> >> we could use binary search to optimize it.
> >
> > From what I gather, both of your latest comments, for patches 4 and 5 are
> related to performance impact because of 128 memory regions. My thoughts
> on this are, I will work on an algorithm to optimize as you suggested.
> Meanwhile we could approve patches 1-4. The rest of the implementation does
> not need 128 memory regions. The existing 8 regions are fine. I put in this
> change as I felt it makes the system scale more and was also suggested by
> Maxime. I think patches 1-4 stand by themselves and have been thoroughly
> tested. Please let me know your thoughts on this.
>
> I am OK for this.

Thank you for the quick response. I have just submitted v5 of the patchset where I removed the patch which increases the memory regions to 128. Please Ack and help merge to mainline.

>
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>>  #define VHOST_USER_NET_SUPPORTED_FEATURES \
> >>>>>     (VIRTIO_NET_SUPPORTED_FEATURES | \
> >>>
> >>>
> >
> >
  

Patch

diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index 5a0e747b58..c6ad5b76d6 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -11,7 +11,7 @@ 
 
 /* refer to hw/virtio/vhost-user.c */
 
-#define VHOST_MEMORY_MAX_NREGIONS 8
+#define VHOST_MEMORY_MAX_NREGIONS 128
 
 #define VHOST_USER_NET_SUPPORTED_FEATURES \
 	(VIRTIO_NET_SUPPORTED_FEATURES | \