On 5/8/2026 11:16 AM, Morten Brørup wrote:
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?


No specific timeline, unfortunately.

--
Thanks,
Anatoly

Reply via email to