On Mon, 2016-07-11 at 15:43 +0000, Luca Boccassi wrote: > On Mon, 2016-07-11 at 13:02 +0100, Luca Boccassi wrote: > > 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. > > I was now able to solve this use case, by having the rte_eth_dev_reset > implementations return -EAGAIN if the dev is not up. This way I know, in > the application, that I have to try again. What do you think? > > IMHO it makes sense, as the reset does not actually succeeds, and the > caller should try again. The diff is very trivial, and attached for > reference.
Hi, Is there any update on resubmitting this patchset for 16.11? Thanks! -- Kind regards, Luca Boccassi
