From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id D717B5A0A for ; Fri, 23 Sep 2016 11:20:52 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 23 Sep 2016 02:20:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,381,1470726000"; d="scan'208";a="883005189" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.45]) by orsmga003.jf.intel.com with SMTP; 23 Sep 2016 02:20:49 -0700 Received: by (sSMTP sendmail emulation); Fri, 23 Sep 2016 10:20:48 +0025 Date: Fri, 23 Sep 2016 10:20:48 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: "Iremonger, Bernard" , dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak Message-ID: <20160923092048.GA58328@bricha3-MOBL3> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <1616711.yO3pyfy9gD@xps13> <8CEF83825BEC744B83065625E567D7C21A08123A@IRSMSX108.ger.corp.intel.com> <3664576.rt1sgYQyhm@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3664576.rt1sgYQyhm@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 09:20:53 -0000 On Thu, Sep 22, 2016 at 07:04:37PM +0200, Thomas Monjalon wrote: > 2016-09-15 16:46, Iremonger, Bernard: > > > > > Do we really need to expose VF specific functions here? > > > > > It can be generic(PF/VF) function indexed only through port_id. > > > > > (example: as rte_eth_dev_set_vlan_anti_spoof(uint8_t port_id, > > > > > uint8_t on)) For instance, In Thunderx PMD, We are not exposing a > > > > > separate port_id for PF. We only enumerate 0..N VFs as 0..N ethdev > > > > > port_id > > > > > > > > Our intention with this patch is to control the VF from the PF. > > > > > > > > The following librte_ether functions already work in a similar way: > > > > > > > > rte_eth_dev_set_vf_rxmode(uint8_t port_id, uint16_t vf, uint16_t > > > > rx_mode, uint8_t on) > > > > > > > > rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on) > > > > > > > > rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on) > > > > > > > > int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, uint16_t > > > > tx_rate, uint64_t q_msk) > > > > > > I have a bad feeling with these functions dedicated to VF from PF. > > > Are we sure there is no other way? > > > I mean we just need to know the VF with a port ID. > > > > When the VF is used in a VM the port ID of the VF is not visible to the PF. > > I don't think there is another way to do this. > > I don't understand why we could not assign a port id to the VF from the > host instead of having the couple PF port id / VF id. > Can we enumerate all the VFs associated to a PF? > Then can we allocate them a port id in the array rte_eth_devices? Hi Thomas, The VF is not a port visible to DPDK, though, so it shouldn't have a port id IMHO. DPDK can't actually do anything with it. The PCI device for the VF is likely passed through to a different VM and being used there. Unfortunately, the VF still needs certain things done for it by the PF, so if the PF is under DPDK control, it needs to provide the functionality to assist the VF. /Bruce