From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 92035A0613 for ; Thu, 29 Aug 2019 17:02:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 794381C1F3; Thu, 29 Aug 2019 17:02:17 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 66BC91C1F1 for ; Thu, 29 Aug 2019 17:02:15 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2019 08:02:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,443,1559545200"; d="scan'208";a="171920722" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga007.jf.intel.com with ESMTP; 29 Aug 2019 08:02:12 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.50]) by IRSMSX101.ger.corp.intel.com ([169.254.1.61]) with mapi id 14.03.0439.000; Thu, 29 Aug 2019 16:02:11 +0100 From: "Iremonger, Bernard" To: Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko CC: "dev@dpdk.org" , Shahaf Shuler , "E. Scott Daniels" , "Lu, Wenzhuo" , Alex Zelezniak , Ajit Khaparde , "Doherty, Declan" Thread-Topic: [RFC] ethdev: configure SR-IOV VF from host Thread-Index: AQHVU3sD1V5XhiteIkWvHNFCROxovqcSRNKQ Date: Thu, 29 Aug 2019 15:02:11 +0000 Message-ID: <8CEF83825BEC744B83065625E567D7C260DE9D47@IRSMSX108.ger.corp.intel.com> References: <4165509.5enYigmRGf@xps> In-Reply-To: <4165509.5enYigmRGf@xps> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGQ1MjdhZjYtM2JlNC00YjMyLTkxODItOGE5MGMwYzc2NmFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiK1E4MWo2T2syUEEwRnNvWkNwY0psT05MVVJCWHlXekQ4MlQ0MU1jWGJuYW9SbytYeFoyNU8wdDhSZGkwTkNTSiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] ethdev: configure SR-IOV VF from host 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday, August 15, 2019 4:06 PM > To: Yigit, Ferruh ; Andrew Rybchenko > > Cc: dev@dpdk.org; Iremonger, Bernard ; > Shahaf Shuler ; E. Scott Daniels > ; Lu, Wenzhuo ; Alex > Zelezniak ; Ajit Khaparde ; > Doherty, Declan > Subject: [RFC] ethdev: configure SR-IOV VF from host >=20 > In a virtual environment, the network controller may have to configure so= me > SR-IOV VF parameters for security reasons. >=20 > When the PF (host port) is drived by DPDK (OVS-DPDK case), we face two > different cases: > - driver is bifurcated (Mellanox case), > so the VF can be configured via the kernel. > - driver is on top of UIO or VFIO, so DPDK API is required. >=20 > This RFC proposes to use generic DPDK API for VF configuration. > The impacted functions are (can be extended): >=20 > - rte_eth_dev_is_valid_port > - rte_eth_promiscuous_enable > - rte_eth_promiscuous_disable > - rte_eth_promiscuous_get > - rte_eth_allmulticast_enable > - rte_eth_allmulticast_disable > - rte_eth_allmulticast_get > - rte_eth_dev_set_mc_addr_list > - rte_eth_dev_default_mac_addr_set > - rte_eth_macaddr_get > - rte_eth_dev_mac_addr_add > - rte_eth_dev_mac_addr_remove > - rte_eth_dev_vlan_filter > - rte_eth_dev_get_mtu > - rte_eth_dev_set_mtu >=20 > In order to target these functions to a VF (which has no port id in the h= ost), > the higher bit of port id is reserved: >=20 > #define RTE_ETH_VF_PORT_FLAG (1 << 15) >=20 > This bit can be combined only with the port id of a representor. > The meaning is to target the VF connected with the representor port, inst= ead > of the representor port itself. >=20 > If a function is not expected to support VF configuration, it will return= - > EINVAL, i.e. there is no code change. > If an API function (listed above) can support VF configuration, but the P= MD > does not support it, then -ENOTSUP must be returned. >=20 > As an example, this is the change required in rte_eth_dev_is_valid_port: >=20 > int > rte_eth_dev_is_valid_port(uint16_t port_id) { > + uint32_t dev_flags; > + uint16_t vf_flag; > + > + vf_flag =3D port_id & RTE_ETH_VF_PORT_FLAG; > + port_id &=3D RTE_ETH_VF_PORT_FLAG - 1; /* remove VF flag */ > + > if (port_id >=3D RTE_MAX_ETHPORTS || > (rte_eth_devices[port_id].state =3D=3D RTE_ETH_DEV_UNUSED)) > return 0; > - else > - return 1; > + > + dev_flags =3D rte_eth_dev_shared_data->data[port_id].dev_flags; > + if (vf_flag !=3D 0 && (dev_flags & RTE_ETH_DEV_REPRESENTOR) =3D= =3D 0) > + return 0; /* VF flag has no meaning if not a representor > + */ > + > + return 1; > } >=20 >=20 Some of the functions in the list above for example, rte_eth_dev_promiscuou= s_enable() use the dev_ops structure, is it intended to add more rte_eth_de= v_* functions to the dev_ops structure? At present the ixgbe and i40e PMD's have sets of private functions for conf= iguring SRIOV VF's from the DPDK PF, rte_pmd_ixgbe_* and rte_pmd_i40e_* f= unctions (see rte_pmd_ixgbe.h and rte_pmd_i40e.h). At the time these functions were not allowed to be added to the dev_ops str= ucture as there were so many of them. There was a proposal to add a dev_ct= rl function to the dev_ops structure which would access the private functio= ns. Maybe adding the dev_ctrl function should be considered again. Having two ways (through dev_ops and private PMD functions) to configure DP= DK VF's from the DPDK PF will be confusing for developers. Regards, Bernard.