From: "Richardson, Bruce" <bruce.richardson@intel.com>
To: "Polehn, Mike A" <mike.a.polehn@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 15:51:09 +0000 [thread overview]
Message-ID: <59AF69C657FD0841A61C55336867B5B035969499@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <745DB4B8861F8E4B9849C970520ABBF1497577D1@ORSMSX102.amr.corp.intel.com>
> -----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 15:51 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 [this message]
2015-11-05 17:59 ` Polehn, Mike A
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=59AF69C657FD0841A61C55336867B5B035969499@IRSMSX103.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=ShahamF@Radware.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).