On 09/23/2015 07:35 PM, YeYin wrote: > Hi, all, > > > When I enable SR-IOV with ixgbevf: > > [ 56.126379] ixgbevf 0000:01:10.0: enabling device (0000 -> 0002) > [ 56.263462] ixgbevf 0000:01:10.0: PF still in reset state. Is the PF > interface up? > [ 56.355415] ixgbevf 0000:01:10.0: Assigning random MAC address > [ 56.425444] ixgbevf: probe of 0000:01:10.0 failed with error -15 > > > > However I enable SR-IOV with igbvf: > > > [ 63.974721] igbvf 0000:01:12.1: enabling device (0000 -> 0002) > [ 64.044339] igbvf 0000:01:12.1: irq 151 for MSI/MSI-X > [ 64.044350] igbvf 0000:01:12.1: irq 152 for MSI/MSI-X > [ 64.044360] igbvf 0000:01:12.1: irq 153 for MSI/MSI-X > [ 64.045505] igbvf 0000:01:12.1: PF still in reset state. Is the PF > interface up? > [ 64.133980] igbvf 0000:01:12.1: Assigning random MAC address. > [ 64.203651] igbvf 0000:01:12.1: PF still resetting > [ 64.260990] igbvf 0000:01:12.1: Intel(R) I350 Virtual Function > [ 64.330564] igbvf 0000:01:12.1: Address: 0e:ce:51:a0:4b:9f > > > > As we can see, igbvf will complete VF initialization when found PF in reset > state. However, ixgbevf will return error(IXGBE_ERR_RESET_FAILED) when found > PF in reset state. Obviously, igbvf ignored this error. > However, the following was written on the 82576 datasheet: > > > Until a RSTD condition is detected, the VFs should access only the VFMailbox > register and should not attempt to activate the interrupt mechanism or the > transmit and receive process. > > > Is this a bug of igbvf ? > > > Thanks, > Ye
It's just a difference of opinion in implementation. Back when I worked on igbvf I felt that it should allow you to load the driver even if the PF is not present as trying to reload it after the fact can be a pain. So as a result the igbvf driver will assign itself a random MAC address and report link down until the PF is loaded. One side effect of that is that it will come up with a random MAC address in that situation so if you do this frequently you might notice udev creating a number of rules for ethX interfaces if it isn't using PCIe slot naming. The decision for the ixgbevf driver was to require a the user to reload/rescan if the VF driver is loaded before the PF is up. This forced the interface to wait until the PF was up and ready to assign MAC addresses so that the VF should have a consistent address. Though I think there might be a code difference in the end of the function ixgbevf_sw_init between the driver on e1000.sf.net and the one in the Linux kernel. From what I can tell the one in the kernel might load with a random MAC address like igbvf while the out-of-tree driver will fail with the error as you have described. - Alex ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
