Hi Luca,
> -----Original Message----- > From: Luca Boccassi [mailto:lboccass at Brocade.com] > Sent: Friday, August 26, 2016 8:58 PM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link > > 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! Sorry, we're short of hands, so this feature is planned to R17.02. > > -- > Kind regards, > Luca Boccassi
