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 EA43D1B010 for ; Wed, 10 Jan 2018 08:57:00 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 23:56:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,339,1511856000"; d="scan'208";a="25972411" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 09 Jan 2018 23:56:59 -0800 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 9 Jan 2018 23:56:59 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 9 Jan 2018 23:56:59 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.159]) by shsmsx102.ccr.corp.intel.com ([169.254.2.189]) with mapi id 14.03.0319.002; Wed, 10 Jan 2018 15:56:47 +0800 From: "Xing, Beilei" To: "Horton, Remy" , "dev@dpdk.org" CC: "Mcnamara, John" , "Lu, Wenzhuo" , "Wu, Jingjing" , "Doherty, Declan" , "Awal, Mohammad Abdul" Thread-Topic: [dpdk-dev] [PATCH v4 3/5] drivers/net/i40e: add Port Representor functionality Thread-Index: AQHTiI5W/JFRlWnCLUyvWk0tGSINlqNsuReA Date: Wed, 10 Jan 2018 07:56:47 +0000 Message-ID: <94479800C636CB44BD422CB454846E0132089D9F@SHSMSX101.ccr.corp.intel.com> References: <20180108143720.7994-1-remy.horton@intel.com> <20180108143720.7994-4-remy.horton@intel.com> In-Reply-To: <20180108143720.7994-4-remy.horton@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 10 Jan 2018 07:57:01 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Remy Horton > Sent: Monday, January 8, 2018 10:37 PM > To: dev@dpdk.org > Cc: Mcnamara, John ; Lu, Wenzhuo > ; Wu, Jingjing ; Doherty, > Declan ; Awal, Mohammad Abdul > > Subject: [dpdk-dev] [PATCH v4 3/5] drivers/net/i40e: add Port Representor > functionality >=20 > 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 par= ent > 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. >=20 > This patch adds to the i40e PMD the functions required to enable port > representor functionality. >=20 > Signed-off-by: Declan Doherty > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Remy Horton > --- > MAINTAINERS | 2 + > drivers/net/i40e/Makefile | 1 + > drivers/net/i40e/i40e_ethdev.c | 16 ++ > drivers/net/i40e/i40e_ethdev.h | 1 + > drivers/net/i40e/i40e_prep_ops.c | 495 > +++++++++++++++++++++++++++++++++++++++ > drivers/net/i40e/i40e_prep_ops.h | 15 ++ > drivers/net/i40e/rte_pmd_i40e.c | 47 ++++ > drivers/net/i40e/rte_pmd_i40e.h | 18 ++ > 8 files changed, 595 insertions(+) > create mode 100644 drivers/net/i40e/i40e_prep_ops.c create mode 100644 > drivers/net/i40e/i40e_prep_ops.h <...> > + dev_info->rx_offload_capa =3D > + DEV_RX_OFFLOAD_VLAN_STRIP | > + DEV_RX_OFFLOAD_QINQ_STRIP | > + DEV_RX_OFFLOAD_IPV4_CKSUM | > + DEV_RX_OFFLOAD_UDP_CKSUM | > + DEV_RX_OFFLOAD_TCP_CKSUM; > + dev_info->tx_offload_capa =3D > + DEV_TX_OFFLOAD_VLAN_INSERT | > + DEV_TX_OFFLOAD_QINQ_INSERT | > + DEV_TX_OFFLOAD_IPV4_CKSUM | > + DEV_TX_OFFLOAD_UDP_CKSUM | > + DEV_TX_OFFLOAD_TCP_CKSUM | > + DEV_TX_OFFLOAD_SCTP_CKSUM; Tunnel TSO and outer IP checksum are also supported. <...> > +static const struct ether_addr null_mac_addr; > + > +int > +rte_pmd_i40e_remove_vf_mac_addr(uint8_t port, uint16_t vf_id, > + struct ether_addr *mac_addr) > +{ > + struct rte_eth_dev *dev; > + struct i40e_pf_vf *vf; > + struct i40e_vsi *vsi; > + struct i40e_pf *pf; > + > + if (i40e_validate_mac_addr((u8 *)mac_addr) !=3D I40E_SUCCESS) > + return -EINVAL; > + > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV); > + > + dev =3D &rte_eth_devices[port]; > + > + if (!is_i40e_supported(dev)) > + return -ENOTSUP; > + > + pf =3D I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private); > + > + if (vf_id >=3D pf->vf_num || !pf->vfs) > + return -EINVAL; > + > + vf =3D &pf->vfs[vf_id]; > + vsi =3D vf->vsi; > + if (!vsi) { > + PMD_DRV_LOG(ERR, "Invalid VSI."); > + return -EINVAL; > + } > + > + if (!is_same_ether_addr(mac_addr, &vf->mac_addr)) { > + PMD_DRV_LOG(ERR, "Mac address does not match."); > + return -EINVAL; > + } Not very understand why only vf->mac_addr can be moved? I think any mac add= ress in vsi->mac_list can be removed. > + > + /* reset the mac with null mac */ > + ether_addr_copy(&null_mac_addr, &vf->mac_addr); > + > + /* Remove the mac */ > + i40e_vsi_delete_mac(vsi, mac_addr); > + > + return 0; > +} > +