Discussion:
Difference between igbvf and ixgbevf driver about RSTD/RSTI
(too old to reply)
YeYin
2015-09-24 02:35:46 UTC
Permalink
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
Alexander Duyck
2015-09-24 02:59:42 UTC
Permalink
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

Loading...