* [dpdk-dev] SR-IOV: API to tell VF from PF
@ 2015-11-05 9:39 Shaham Fridenberg
2015-11-05 9:50 ` Bruce Richardson
0 siblings, 1 reply; 6+ messages in thread
From: Shaham Fridenberg @ 2015-11-05 9:39 UTC (permalink / raw)
To: dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] SR-IOV: API to tell VF from PF
2015-11-05 9:39 [dpdk-dev] SR-IOV: API to tell VF from PF Shaham Fridenberg
@ 2015-11-05 9:50 ` Bruce Richardson
2015-11-05 15:43 ` Polehn, Mike A
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Richardson @ 2015-11-05 9:50 UTC (permalink / raw)
To: Shaham Fridenberg; +Cc: dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] SR-IOV: API to tell VF from PF
2015-11-05 9:50 ` Bruce Richardson
@ 2015-11-05 15:43 ` Polehn, Mike A
2015-11-05 15:51 ` Richardson, Bruce
0 siblings, 1 reply; 6+ messages in thread
From: Polehn, Mike A @ 2015-11-05 15:43 UTC (permalink / raw)
To: Richardson, Bruce, Shaham Fridenberg; +Cc: dev
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
-----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] SR-IOV: API to tell VF from PF
2015-11-05 15:43 ` Polehn, Mike A
@ 2015-11-05 15:51 ` Richardson, Bruce
2015-11-05 17:59 ` Polehn, Mike A
0 siblings, 1 reply; 6+ messages in thread
From: Richardson, Bruce @ 2015-11-05 15:51 UTC (permalink / raw)
To: Polehn, Mike A, Shaham Fridenberg; +Cc: dev
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] SR-IOV: API to tell VF from PF
2015-11-05 15:51 ` Richardson, Bruce
@ 2015-11-05 17:59 ` Polehn, Mike A
2015-11-05 21:45 ` Ananyev, Konstantin
0 siblings, 1 reply; 6+ messages in thread
From: Polehn, Mike A @ 2015-11-05 17:59 UTC (permalink / raw)
To: Richardson, Bruce, Shaham Fridenberg; +Cc: dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] SR-IOV: API to tell VF from PF
2015-11-05 17:59 ` Polehn, Mike A
@ 2015-11-05 21:45 ` Ananyev, Konstantin
0 siblings, 0 replies; 6+ messages in thread
From: Ananyev, Konstantin @ 2015-11-05 21:45 UTC (permalink / raw)
To: Polehn, Mike A, Richardson, Bruce, Shaham Fridenberg; +Cc: dev
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-11-05 21:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-05 9:39 [dpdk-dev] SR-IOV: API to tell VF from PF 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 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).