Hi Thomas,
On 22/9/2017 10:56 AM, Thomas Monjalon wrote:
25/08/2017 18:02, David Hunt:+static inline uint64_t +vfid_to_pfid_direct(uint8_t port_id, uint64_t vfid) +{ + struct rte_eth_dev *dev = &rte_eth_devices[port_id]; + uint64_t pfid = (*dev->dev_ops->vfid_to_pfid)(dev, vfid); + return pfid; +}I would like to comment this API but there is no associated doxygen.
Sure, we'll add Doxygen comments.
If the application is aware of the VFs, it probably already knows how PF and VF are associated. Until now, the functions to control VF from PF are driver-specifics.
Working out the relationship between the PF and the VF has turned out to be quite a challenge. :)
The application on the guest is aware of the VFs. The application on the host is aware of the PF and can access the VFs through the PF. However, the application on the host is not aware of how each VF on VM associates as which VF on the PF. I.E. the PF needs to know which index in its array of VFs the VF in use by the guest application is stored at. This is what this additional function is used for. It gives the PF the index of the VF in question in its array of VFs. We have researched alternative ways to determine this association but this is the only method that provides this functionality. Without this the PF does not know how each VF is associated with PF.
We also realize that the mac addresses need to be in sync between the host and the guest for correct operation of this scheme.
As mentioned in my previous mail, we are working on an updated patch set, targeting early next week.
Regards, Dave.
