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 4F74B8E56 for ; Thu, 5 Nov 2015 16:43:14 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 05 Nov 2015 07:43:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,248,1444719600"; d="scan'208";a="828034677" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga001.fm.intel.com with ESMTP; 05 Nov 2015 07:43:13 -0800 Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 5 Nov 2015 07:43:12 -0800 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.190]) by ORSMSX111.amr.corp.intel.com ([169.254.11.251]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 07:43:12 -0800 From: "Polehn, Mike A" To: "Richardson, Bruce" , Shaham Fridenberg Thread-Topic: [dpdk-dev] SR-IOV: API to tell VF from PF Thread-Index: AdEXrYOqrq2ZCfPKTseY27szvYZGZQARP90AAAS7sxA= Date: Thu, 5 Nov 2015 15:43:12 +0000 Message-ID: <745DB4B8861F8E4B9849C970520ABBF1497577D1@ORSMSX102.amr.corp.intel.com> References: <2E654B490240B7449C846A96A8D8FE0CC43A4C67@ILMB2.corp.radware.com> <20151105095052.GA15324@bricha3-MOBL3> In-Reply-To: <20151105095052.GA15324@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiI4MjM3MWQyMC01MzQwLTQzYzQtOTIxOC1mZWU4NDY3YWVkOTMiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfSUMifV19XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTUuNC4xMC4xOSIsIlRydXN0ZWRMYWJlbEhhc2giOiJnelIxSFZuZXhNNVF1dUV1SzdLZmVxSGZnNzl0OWtpcUluOEl4UjVTZnYwPSJ9 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 15:43:14 -0000 I can think of a very good reason to want to know if the device is VF or PF= .=20 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 ad= dresses. This allow the packets to be just data and allows the processing o= f data without needing to be adjusting each NIC L2 address before sending t= hrough to the Ehternet. So data can be moved through a series of NICs betwe= en systems without the extra processing. Not doing unnecessary processing = leaves more clock cycles to do high value processing. Mike -----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, >=20 > Is there some API to tell VF from PF? >=20 > Only way I found so far is deducing that from driver name in the rte_eth_= devices struct. >=20 > Thanks, > Shaham Hi Shaham, yes, checking the driver name is probably the only way to do so. However, w= hy do you need or want to know this? If you want to know the capabilities o= f a device basing it on a list of known device types is probably not the be= st way. Regards, /Bruce