From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id DB0A92BC8 for ; Tue, 9 Jan 2018 23:09:12 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 14:09:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,337,1511856000"; d="scan'208";a="9471139" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.48]) ([10.237.220.48]) by orsmga008.jf.intel.com with ESMTP; 09 Jan 2018 14:09:10 -0800 To: Remy Horton , dev@dpdk.org Cc: John McNamara , Wenzhuo Lu , Jingjing Wu , Declan Doherty , Mohammad Abdul Awal References: <20180108143720.7994-1-remy.horton@intel.com> <20180108143720.7994-4-remy.horton@intel.com> From: Ferruh Yigit Message-ID: Date: Tue, 9 Jan 2018 22:09:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180108143720.7994-4-remy.horton@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 3/5] drivers/net/i40e: add Port Representor functionality 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: Tue, 09 Jan 2018 22:09:13 -0000 On 1/8/2018 2:37 PM, Remy Horton wrote: > Port Representors provide a logical presentation in DPDK of VF (virtual > function) ports for the purposes of control and monitoring. Each port > representor device represents a single VF and is associated with it's > parent physical function (PF) PMD which provides the back-end hooks for > the representor device ops and defines the control domain to which that > port belongs. This allows to use existing DPDK APIs to monitor and control > the port without the need to create and maintain VF specific APIs. > > This patch adds to the i40e PMD the functions required to enable port > representor functionality. > > Signed-off-by: Declan Doherty > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Remy Horton <...> > @@ -85,6 +85,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c > SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_flow.c > SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += rte_pmd_i40e.c > SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_tm.c > +SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_prep_ops.c This library should be a dependency to the driver now right? May need to update both LDLIBS here. <...> > @@ -1428,6 +1440,10 @@ eth_i40e_dev_uninit(struct rte_eth_dev *dev) > pci_dev = RTE_ETH_DEV_TO_PCI(dev); > intr_handle = &pci_dev->intr_handle; > > + /* free port representor pmds */ > + if (rte_representor_enabled()) > + rte_representor_broker_uninit(pf->broker); Shouldn't this free the "broker" allocated by i40e_port_representor_broker_init? <...> > +int > +rte_pmd_i40e_remove_vf_mac_addr(uint8_t port, uint16_t vf_id, > + struct ether_addr *mac_addr) port_id should be uint16_t <...> > /** > + * Remove the VF MAC address. > + * > + * @param port > + * The port identifier of the Ethernet device. > + * @param vf_id > + * VF id. > + * @param mac_addr > + * VF MAC address. > + * @return > + * - (0) if successful. > + * - (-ENODEV) if *port* invalid. > + * - (-EINVAL) if *vf* or *mac_addr* is invalid. > + */ > +int > +rte_pmd_i40e_remove_vf_mac_addr(uint8_t port, uint16_t vf_id, > + struct ether_addr *mac_addr); > + New PMD specific API requires updating .map file for shared library.