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: Friday, 22 May 2026 11.46
> 
> On 5/8/2026 11:16 AM, Morten Brørup wrote:
> >> 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?
> >
> 
> No specific timeline, unfortunately.

The drivers were very recently updated to use memcpy() instead of rte_memcpy(), so now we can enable stringop-overflow warnings in rte_memcpy().
What really annoyed me was the need to disable these warnings in a general library function due to some drivers.

Since this problem has now been resolved, and the scope of the elems[1] problem has shrunk from system-wide to Intel drivers only, I'm not that concerned about timeline anymore. ;-)

-Morten