[PATCH] net/cpfl: fix VF ID calculation for vCPF

[Bruce Richardson]

On Thu, Sep 10, 2026 at 04:13:07AM +0100, Patel, Atul wrote:
> Hi Bruce,
> 
> Thanks for the review,
> No, the vf_id is not meant to be globally unique across the system - it stays local to the PF, same as other devices. The pf_id here is fixed to a single CPF (CPFL_HOST0_CPF_ID), and the control plane expects the vf_id in struct cpchnl2_func_id to be relative to that PF (the header even documents it as "indexing is relative to PF specified above").
> 
> The subtlety is purely in how those VFs are presented on the host side in the vCPF model. The VFs belonging to that one PF are exposed to the host spread across multiple PCI devices, with 8 functions each. So the PCI function number alone isn't enough to recover the PF-relative vf_id - it wraps every 8 functions.
> 
> For example, with VFs enumerated on bus 0000:af:
> PCI BDF        device  function   ->  vf_id
> 0000:af:00.0     0        0             0
> 0000:af:00.1     0        1             1
> ...
> 0000:af:00.7     0        7             7
> 0000:af:01.0     1        0             8
> 0000:af:01.1     1        1             9
> ...
> 0000:af:01.7     1        7            15
> 0000:af:02.0     2        0            16
> 
> The macro just reconstructs that PF-relative index from the PCI address:
> 	vf_id = device * 8 + function
> 
> The previous code used pci_dev->addr.function directly, so it only worked for the first device (VF 0-7) and collided for every VF on a subsequent device - e.g. 0000:af:01.0 (VF 8) was incorrectly reported as VF 0.
>
Thanks, that is clear now.

/Bruce