[dpdk-dev] SR-IOV: API to tell VF from PF

[Richardson, Bruce]

> -----Original Message-----
> From: Polehn, Mike A
> Sent: Thursday, November 5, 2015 3:43 PM
> To: Richardson, Bruce <bruce.richardson at intel.com>; Shaham Fridenberg
> <ShahamF at Radware.com>
> Cc: dev at 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
> 

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 mode, for instance, or a bifurcated driver where the kernel part prevents the userspace part from enabling promiscuous mode? In both these cases have a direct feature query works better than asking about PF/VF.

Regards,

/Bruce

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, November 5, 2015 1:51 AM
> To: Shaham Fridenberg
> Cc: dev at 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