Difference between igbvf and ixgbevf driver about RSTD/RSTI

Alexander Duyck

2015-09-24 02:59:42 UTC

Post by YeYin
Hi, all,
[ 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
[ 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.
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