> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Polehn, Mike A > Sent: Thursday, November 05, 2015 5:59 PM > To: Richardson, Bruce; Shaham Fridenberg > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] SR-IOV: API to tell VF from PF > > A VF should support promiscuous mode, however this is different than a PF > supporting 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.
In the usual model it is not up to VF/VM to decide what fraction of the total device resources it allowed to use. It is responsibility of the PF/Hypervsior to devide total device bandwidths between VFs/VM, decide which VF will be a mirror if any, etc. Konstantin > > 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 device > type, which should be specific to VF or PF. > > Mike > > -----Original Message----- > From: Richardson, Bruce > Sent: Thursday, November 5, 2015 7:51 AM > To: Polehn, Mike A; Shaham Fridenberg > Cc: dev at 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 <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