From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id B892C8DB5 for ; Thu, 5 Nov 2015 18:59:26 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 05 Nov 2015 09:59:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,248,1444719600"; d="scan'208";a="828144467" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga001.fm.intel.com with ESMTP; 05 Nov 2015 09:59:21 -0800 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.190]) by ORSMSX110.amr.corp.intel.com ([169.254.3.225]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 09:59:17 -0800 From: "Polehn, Mike A" To: "Richardson, Bruce" , Shaham Fridenberg Thread-Topic: [dpdk-dev] SR-IOV: API to tell VF from PF Thread-Index: AdEXrYOqrq2ZCfPKTseY27szvYZGZQARP90AAAS7sxAAB9l9gAAMixEA Date: Thu, 5 Nov 2015 17:59:14 +0000 Message-ID: <745DB4B8861F8E4B9849C970520ABBF149759985@ORSMSX102.amr.corp.intel.com> References: <2E654B490240B7449C846A96A8D8FE0CC43A4C67@ILMB2.corp.radware.com> <20151105095052.GA15324@bricha3-MOBL3> <745DB4B8861F8E4B9849C970520ABBF1497577D1@ORSMSX102.amr.corp.intel.com> <59AF69C657FD0841A61C55336867B5B035969499@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B035969499@IRSMSX103.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiJmNDVjYTFiNi0zYTFiLTQyZDQtYTE3Mi1jYjBmMzU1ZmQ4YTgiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfSUMifV19XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTUuNC4xMC4xOSIsIlRydXN0ZWRMYWJlbEhhc2giOiIrMGZGbDVcL3pXXC9SdlQ1c0pLMkkwMUxkMFRpNkFSK243SWxtU1wvaThzZnNrPSJ9 x-inteldataclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] SR-IOV: API to tell VF from PF 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: Thu, 05 Nov 2015 17:59:27 -0000 A VF should support promiscuous mode, however this is different than a PF s= upporting promiscuous mode. What happens to network throughput, which is tied to PCEe throughput, when = say when 4 VFs are each in promiscuous mode. It should support it, but very= negative effect. Not all NICs are created equal. The program should be able to quarry the de= vice driver and be able to determine if it is the correct NIC type is being= used. The device driver type should only match to the device type, which s= hould be specific to VF or PF. Mike -----Original Message----- From: Richardson, Bruce=20 Sent: Thursday, November 5, 2015 7:51 AM To: Polehn, Mike A; Shaham Fridenberg Cc: dev@dpdk.org Subject: RE: [dpdk-dev] SR-IOV: API to tell VF from PF > -----Original Message----- > From: Polehn, Mike A > Sent: Thursday, November 5, 2015 3:43 PM > To: Richardson, Bruce ; Shaham Fridenberg=20 > > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] SR-IOV: API to tell VF from PF >=20 > I can think of a very good reason to want to know if the device is VF=20 > or PF. >=20 > The VF has to go through a layer 2 switch, not allowing it to just=20 > receive anything coming across the Ehternet. >=20 > The PF can receive all the packets, including packets with different=20 > NIC addresses. This allow the packets to be just data and allows the=20 > processing of data without needing to be adjusting each NIC L2 address=20 > before sending through to the Ehternet. So data can be moved through a=20 > series of NICs between systems without the extra processing. Not doing=20 > unnecessary processing leaves more clock cycles to do high value=20 > processing. >=20 > Mike >=20 Yes, the capabilities of the different types of devices are different. However, is a better solution not to provide the ability to query a NIC if = it supports promiscuous mode, rather than set up a specific query for a VF?= What if (hypothetically) you get a PF that doesn't support promiscuous mod= e, for instance, or a bifurcated driver where the kernel part prevents the = userspace part from enabling promiscuous mode? In both these cases have a d= irect feature query works better than asking about PF/VF. Regards, /Bruce > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Thursday, November 5, 2015 1:51 AM > To: Shaham Fridenberg > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] SR-IOV: API to tell VF from PF >=20 > On Thu, Nov 05, 2015 at 09:39:19AM +0000, Shaham Fridenberg wrote: > > Hey all, > > > > Is there some API to tell VF from PF? > > > > Only way I found so far is deducing that from driver name in the > rte_eth_devices struct. > > > > Thanks, > > Shaham >=20 > Hi Shaham, >=20 > yes, checking the driver name is probably the only way to do so.=20 > However, why do you need or want to know this? If you want to know the=20 > capabilities of a device basing it on a list of known device types is=20 > probably not the best way. >=20 > Regards, > /Bruce