Hi Luca,

-----Original Message-----
From: Luca Boccassi [mailto:lboccass@Brocade.com]
Sent: Friday, August 26, 2016 8:58 PM
To: Lu, Wenzhuo
Cc: dev@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:

quoted

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?

quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

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