On Mon, 2016-07-11 at 01:32 +0000, Lu, Wenzhuo wrote: > > > > Unfortunately I found one issue: if PF is down, and then the VF on the > > guest is > > down as well (ip link down) and then goes back up before the PF, then > > calling > > rte_eth_dev_reset will return 0 (success), even though the PF is still down > > and it > > should fail. This is with ixgbe. Any idea what could be the problem? > I've found this interesting thing. I believe it?s the HW difference between > igb and ixgbe. When the link is down, ixgbe VF can be reset successfully but > igb VF cannot. The expression is the registers of the ixgbe VF can be > accessed when the PF link is down but igb VF cannot. > It means, on ixgbe, when PF link is down, we reset the VF link. Then PF link > is up, we receive the message again and reset the VF link again.
What message do you refer to here? I am seeing the RESET callback only when the PF goes down, not when it goes up. At the moment, with ixgbe, this happens: PF down -> reset notification, rte_eth_dev_reset keeps failing -> VF down -> VF up -> rte_eth_dev_reset in a loop/timer succeeds -> PF up -> VF link has no-carrier, and traffic does NOT go through The problem is that there is just no way of being notified that PF is up, and if rte_eth_dev_reset succeeds I have no way of knowing that I need to run it again. > But on igb, when PF link is down, we cannot reset VF link successfully, so > when the PF link is up, we cannot receive the message. No trigger for us to > reset the VF link again. That's why on igb we have to try again and again > until it succeed, means until PF link is up. > So the return 0 by rte_eth_dev_reset means the resetting succeeded, not mean > the rx/tx is ready. Rx/tx has to depend on the PF link is up. -- Kind regards, Luca Boccassi
