From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 1F4BE7CFD for ; Fri, 22 Sep 2017 14:39:34 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP; 22 Sep 2017 05:39:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,427,1500966000"; d="scan'208,217";a="1222359188" Received: from dhunt5-mobl1.ger.corp.intel.com (HELO [10.237.220.44]) ([10.237.220.44]) by fmsmga002.fm.intel.com with ESMTP; 22 Sep 2017 05:39:32 -0700 To: Thomas Monjalon Cc: dev@dpdk.org, Nemanja Marjanovic , Rory Sexton , "Macnamara, Chris" References: <1503676941-80981-1-git-send-email-david.hunt@intel.com> <1503676941-80981-2-git-send-email-david.hunt@intel.com> <1548901.33fbra2k2h@xps> From: "Hunt, David" Message-ID: <573483e0-f24f-184f-2a7b-4d9458ba341d@intel.com> Date: Fri, 22 Sep 2017 13:39:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1548901.33fbra2k2h@xps> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 01/10] net/i40e: add API to convert VF Id to PF Id X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:39:35 -0000 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.