From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7C5DB7F1C for ; Thu, 5 Nov 2015 22:45:59 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 05 Nov 2015 13:45:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,248,1444719600"; d="scan'208";a="679215625" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga003.jf.intel.com with ESMTP; 05 Nov 2015 13:45:57 -0800 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 5 Nov 2015 21:45:56 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.75]) by irsmsx112.ger.corp.intel.com ([169.254.1.218]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 21:45:56 +0000 From: "Ananyev, Konstantin" To: "Polehn, Mike A" , "Richardson, Bruce" , Shaham Fridenberg Thread-Topic: [dpdk-dev] SR-IOV: API to tell VF from PF Thread-Index: AdEXrYOqrq2ZCfPKTseY27szvYZGZQAAfFUAAAxOGwAAAB/JMAAEoHIAAAeHd+A= Date: Thu, 5 Nov 2015 21:45:55 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836ABB067@irsmsx105.ger.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> <745DB4B8861F8E4B9849C970520ABBF149759985@ORSMSX102.amr.corp.intel.com> In-Reply-To: <745DB4B8861F8E4B9849C970520ABBF149759985@ORSMSX102.amr.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] 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 21:46:00 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Polehn, Mike A > Sent: Thursday, November 05, 2015 5:59 PM > To: Richardson, Bruce; Shaham Fridenberg > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] SR-IOV: API to tell VF from PF >=20 > A VF should support promiscuous mode, however this is different than a PF= supporting promiscuous mode. >=20 > What happens to network throughput, which is tied to PCEe throughput, whe= n say when 4 VFs are each in promiscuous mode. It > should support it, but very negative effect. In the usual model it is not up to VF/VM to decide what fraction of the tot= al device resources it allowed to use. It is responsibility of the PF/Hypervsior to devide total device bandwidths= between VFs/VM,=20 decide which VF will be a mirror if any, etc. Konstantin >=20 > Not all NICs are created equal. The program should be able to quarry the = device 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 devic= e type, which should be specific to VF or PF. >=20 > Mike >=20 > -----Original Message----- > From: Richardson, Bruce > 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 >=20 >=20 >=20 > > -----Original Message----- > > From: Polehn, Mike A > > Sent: Thursday, November 5, 2015 3:43 PM > > To: Richardson, Bruce ; Shaham Fridenberg > > > > Cc: dev@dpdk.org > > Subject: RE: [dpdk-dev] SR-IOV: API to tell VF from PF > > > > I can think of a very good reason to want to know if the device is VF > > or PF. > > > > The VF has to go through a layer 2 switch, not allowing it to just > > receive anything coming across the Ehternet. > > > > The PF can receive all the packets, including packets with different > > NIC addresses. This allow the packets to be just data and allows the > > processing of data without needing to be adjusting each NIC L2 address > > before sending through to the Ehternet. So data can be moved through a > > series of NICs between systems without the extra processing. Not doing > > unnecessary processing leaves more clock cycles to do high value > > processing. > > > > Mike > > >=20 > Yes, the capabilities of the different types of devices are different. >=20 > However, is a better solution not to provide the ability to query a NIC i= f it supports promiscuous mode, rather than set up a specific > query for a VF? What if (hypothetically) you get a PF that doesn't suppor= t promiscuous mode, for instance, or a bifurcated driver > where the kernel part prevents the userspace part from enabling promiscuo= us mode? In both these cases have a direct feature query > works better than asking about PF/VF. >=20 > Regards, >=20 > /Bruce >=20 > > -----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 > > > > 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 > > > > Hi Shaham, > > > > yes, checking the driver name is probably the only way to do so. > > However, why do you need or want to know this? If you want to know the > > capabilities of a device basing it on a list of known device types is > > probably not the best way. > > > > Regards, > > /Bruce