> From: Burakov, Anatoly [mailto:[email protected]] > 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 > <[email protected]> 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 <[email protected]> > >> --- > >> 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/[email protected]/ [2]: https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/74968218420 -Morten
