[PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[Anatoly Burakov]

The PF will check buffer size for being too big, and the chunk sizing code
correctly calls that out. However, the size was actually still too big
because `struct virtchnl_queue_vector_maps` already had one queue vector
as part of its definition, so `chunk_sz` was too big by 1.

Fixes: 292d3b781ac4 ("net/iavf: replace unnecessary hugepage memory allocations")

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
 drivers/net/intel/iavf/iavf_vchnl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
index c2f340db81..dd09b0fa61 100644
--- a/drivers/net/intel/iavf/iavf_vchnl.c
+++ b/drivers/net/intel/iavf/iavf_vchnl.c
@@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct iavf_adapter *adapter,
 
 	/* for some reason PF side checks for buffer being too big, so adjust it down */
 	buf_len = sizeof(struct virtchnl_queue_vector_maps) +
-		  sizeof(struct virtchnl_queue_vector) * chunk_sz;
+		  sizeof(struct virtchnl_queue_vector) * (chunk_sz - 1);
 
 	args.ops = VIRTCHNL_OP_MAP_QUEUE_VECTOR;
 	args.in_args = (u8 *)map_info;
-- 
2.47.3

Re: [PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[David Marchand]

On Wed, 6 May 2026 at 16:07, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
>
> The PF will check buffer size for being too big, and the chunk sizing code
> correctly calls that out. However, the size was actually still too big
> because `struct virtchnl_queue_vector_maps` already had one queue vector
> as part of its definition, so `chunk_sz` was too big by 1.
>
> Fixes: 292d3b781ac4 ("net/iavf: replace unnecessary hugepage memory allocations")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
>  drivers/net/intel/iavf/iavf_vchnl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
> index c2f340db81..dd09b0fa61 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct iavf_adapter *adapter,
>
>         /* for some reason PF side checks for buffer being too big, so adjust it down */

The comment above can be removed?

>         buf_len = sizeof(struct virtchnl_queue_vector_maps) +
> -                 sizeof(struct virtchnl_queue_vector) * chunk_sz;
> +                 sizeof(struct virtchnl_queue_vector) * (chunk_sz - 1);

- did you make sure you did not break compat with previous version of
Intel out of tree PF driver (since this concerns configuring "Large
VF")?

- all those virtchnl list struct have the same elems[1] issue.
Kernel side did some cleanups some time ago, maybe time for DPDK to do
the same...?


-- 
David Marchand

Re: [PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[Burakov, Anatoly]

On 5/6/2026 5:58 PM, David Marchand wrote:
> On Wed, 6 May 2026 at 16:07, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
>>
>> The PF will check buffer size for being too big, and the chunk sizing code
>> correctly calls that out. However, the size was actually still too big
>> because `struct virtchnl_queue_vector_maps` already had one queue vector
>> as part of its definition, so `chunk_sz` was too big by 1.
>>
>> Fixes: 292d3b781ac4 ("net/iavf: replace unnecessary hugepage memory allocations")
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> ---
>>   drivers/net/intel/iavf/iavf_vchnl.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
>> index c2f340db81..dd09b0fa61 100644
>> --- a/drivers/net/intel/iavf/iavf_vchnl.c
>> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
>> @@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct iavf_adapter *adapter,
>>
>>          /* for some reason PF side checks for buffer being too big, so adjust it down */
> 
> The comment above can be removed?

No, it's still relevant, because it refers to the fact that we're 
adjusting the total length downwards as opposed to leaving it at max size.

> 
>>          buf_len = sizeof(struct virtchnl_queue_vector_maps) +
>> -                 sizeof(struct virtchnl_queue_vector) * chunk_sz;
>> +                 sizeof(struct virtchnl_queue_vector) * (chunk_sz - 1);
> 
> - did you make sure you did not break compat with previous version of
> Intel out of tree PF driver (since this concerns configuring "Large
> VF")?

The commit in question *did* break things with previous out of tree PF 
driver. This commit fixes the breakage introduced in that commit. The 
commit being fixed was a refactor, which specified size as N-1.

> 
> - all those virtchnl list struct have the same elems[1] issue.
> Kernel side did some cleanups some time ago, maybe time for DPDK to do
> the same...?
> 

Yes, it is indeed time to do the same, but not as part of this patchset, 
and not before the base driver code is updated to do the same. There is 
some background work happening on that front already, but there are a 
lot of dependencies and moving parts, so we can't just change this willy 
nilly.

-- 
Thanks,
Anatoly

RE: [PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[Morten Brørup]

> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> Sent: Thursday, 7 May 2026 10.09
> 
> On 5/6/2026 5:58 PM, David Marchand wrote:
> > On Wed, 6 May 2026 at 16:07, Anatoly Burakov
> <anatoly.burakov@intel.com> wrote:
> >>
> >> The PF will check buffer size for being too big, and the chunk
> sizing code
> >> correctly calls that out. However, the size was actually still too
> big
> >> because `struct virtchnl_queue_vector_maps` already had one queue
> vector
> >> as part of its definition, so `chunk_sz` was too big by 1.
> >>
> >> Fixes: 292d3b781ac4 ("net/iavf: replace unnecessary hugepage memory
> allocations")
> >>
> >> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >> ---
> >>   drivers/net/intel/iavf/iavf_vchnl.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> >> index c2f340db81..dd09b0fa61 100644
> >> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> >> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> >> @@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct
> iavf_adapter *adapter,
> >>
> >>          /* for some reason PF side checks for buffer being too big,
> so adjust it down */
> >
> > The comment above can be removed?
> 
> No, it's still relevant, because it refers to the fact that we're
> adjusting the total length downwards as opposed to leaving it at max
> size.
> 
> >
> >>          buf_len = sizeof(struct virtchnl_queue_vector_maps) +
> >> -                 sizeof(struct virtchnl_queue_vector) * chunk_sz;
> >> +                 sizeof(struct virtchnl_queue_vector) * (chunk_sz -
> 1);
> >
> > - did you make sure you did not break compat with previous version of
> > Intel out of tree PF driver (since this concerns configuring "Large
> > VF")?
> 
> The commit in question *did* break things with previous out of tree PF
> driver. This commit fixes the breakage introduced in that commit. The
> commit being fixed was a refactor, which specified size as N-1.
> 
> >
> > - all those virtchnl list struct have the same elems[1] issue.
> > Kernel side did some cleanups some time ago, maybe time for DPDK to
> do
> > the same...?
> >
> 
> Yes, it is indeed time to do the same, but not as part of this
> patchset,
> and not before the base driver code is updated to do the same. There is
> some background work happening on that front already, but there are a
> lot of dependencies and moving parts, so we can't just change this
> willy
> nilly.

Is there a timeline for this fix?

With the performance improved rte_memcpy() patch [1], one of the CI compilers complains about buffer overflows when writing beyond these undersize arrays [2].
And I'd like to see the performance improved rte_memcpy() merged in 26.07.

[1]: https://patchwork.dpdk.org/project/dpdk/patch/20260429103548.220354-1-mb@smartsharesystems.com/
[2]: https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/74968218420

-Morten

RE: [PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[Morten Brørup]

> From: Morten Brørup
> Sent: Friday, 8 May 2026 11.16
> 
> > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > Sent: Thursday, 7 May 2026 10.09
> >
> > On 5/6/2026 5:58 PM, David Marchand wrote:
> > > On Wed, 6 May 2026 at 16:07, Anatoly Burakov
> > <anatoly.burakov@intel.com> wrote:
> > >>
> > >
> > > - all those virtchnl list struct have the same elems[1] issue.
> > > Kernel side did some cleanups some time ago, maybe time for DPDK to
> > do
> > > the same...?
> > >
> >
> > Yes, it is indeed time to do the same, but not as part of this
> > patchset,
> > and not before the base driver code is updated to do the same. There
> is
> > some background work happening on that front already, but there are a
> > lot of dependencies and moving parts, so we can't just change this
> > willy
> > nilly.
> 
> Is there a timeline for this fix?
> 
> With the performance improved rte_memcpy() patch [1], one of the CI
> compilers complains about buffer overflows when writing beyond these
> undersize arrays [2].
> And I'd like to see the performance improved rte_memcpy() merged in
> 26.07.

With v10 of the rte_memcpy() patch [3], I have reverted the removal of the workaround that ignores stringop-overflow warnings in rte_memcpy(), so the patch doesn't depend on fixing the drivers.

Please take note to remove the workaround from rte_memcpy() when the flex array issue in the drivers - using elems[1] instead of elems[] - has been fixed.
Not ignoring buffer overflows in rte_memcpy() might help reveal bugs elsewhere.

Alternatively, move the workaround from rte_memcpy.h to the driver code requiring the workaround.

> 
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20260429103548.220354-1-
> mb@smartsharesystems.com/
> [2]:
> https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/749682184
> 20

[3]: https://patchwork.dpdk.org/project/dpdk/patch/20260508095827.53587-1-mb@smartsharesystems.com/

> 
> -Morten