From: "Polehn, Mike A" <mike.a.polehn@intel.com>
To: "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 17:59:14 +0000 [thread overview]
Message-ID: <745DB4B8861F8E4B9849C970520ABBF149759985@ORSMSX102.amr.corp.intel.com> (raw)
In-Reply-To: <59AF69C657FD0841A61C55336867B5B035969499@IRSMSX103.ger.corp.intel.com>
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.
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
next prev parent reply other threads:[~2015-11-05 17:59 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 [this message]
2015-11-05 21:45 ` Ananyev, Konstantin
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=745DB4B8861F8E4B9849C970520ABBF149759985@ORSMSX102.amr.corp.intel.com \
--to=mike.a.polehn@intel.com \
--cc=ShahamF@Radware.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/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).