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

["Morten Brørup" <mb@smartsharesystems.com>]

> 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