On Mon, 2016-07-11 at 15:43 +0000, Luca Boccassi wrote:

On Mon, 2016-07-11 at 13:02 +0100, Luca Boccassi wrote:

quoted

On Mon, 2016-07-11 at 01:32 +0000, Lu, Wenzhuo wrote:

quoted

quoted

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