[dpdk-dev] [PATCH v6 0/4] support reset of VF link

Luca Boccassi lboccass at Brocade.com
Mon Jul 11 14:02:20 CEST 2016


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


More information about the dev mailing list