From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Polehn, Mike A" <mike.a.polehn@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
Shaham Fridenberg <ShahamF@Radware.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] SR-IOV: API to tell VF from PF
Date: Thu, 5 Nov 2015 21:45:55 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836ABB067@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <745DB4B8861F8E4B9849C970520ABBF149759985@ORSMSX102.amr.corp.intel.com>
> -----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
>
> 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@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@intel.com>; Shaham Fridenberg
> > <ShahamF@Radware.com>
> > 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
> >
>
> 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@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
prev parent reply other threads:[~2015-11-05 21:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 9:39 Shaham Fridenberg
2015-11-05 9:50 ` Bruce Richardson
2015-11-05 15:43 ` Polehn, Mike A
2015-11-05 15:51 ` Richardson, Bruce
2015-11-05 17:59 ` Polehn, Mike A
2015-11-05 21:45 ` Ananyev, Konstantin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB97725836ABB067@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=ShahamF@Radware.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=mike.a.polehn@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).