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

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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