From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41])
by dpdk.org (Postfix) with ESMTP id F3BF82BB2
for <dev@dpdk.org>; Fri, 24 Feb 2017 11:42:59 +0100 (CET)
Received: by mail-wm0-f41.google.com with SMTP id 196so7925000wmm.1
for <dev@dpdk.org>; Fri, 24 Feb 2017 02:42:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=6wind-com.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=1btY3uWlGCoSQ3ZVUvkNDGBuuPANyt9VanZSw4kSVJw=;
b=zZxT43aKZ/8ePqAUw2sZdyf44arrbdRmNsP1sHFzsclbCy3jECwzFKELJE87yfsesi
LKkOXqnQnlPFnKTqm3tsizEM2iMmZsa9SG5FwvG+lV6mLJKa9Fe83pgN7/PkLTktrjSc
MPEw76XG5R4Ef9zWftKR2L98tHzmMVsMagBlCfBHGOHHQvzTRxiGNIOlWAbJEl9L5l4A
ZoMVTN6zKLtZ4b7s79W86C3H+e8xdcOm9CD7Suqf7bWIBTatgO4JVAupaihBsYgxQZiR
7HoaG2RHKtYBNfs2L+Ey6x+dFqLNfFvzqjyW0EOcY9NWZy/VHhxcXiQBN0C+CQJADF11
XVcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=1btY3uWlGCoSQ3ZVUvkNDGBuuPANyt9VanZSw4kSVJw=;
b=mTC+4s7b5Lsmw1XDt52crJKWYwQNHQlnyJSHn65Owas5y3nmFEyobAuLmhxRfoKbdS
6/sZshfcEhuVrSs4kIMli4WnMpg0V45QsAZ48bfEDFGvnqGCmUtExQNS1OqIz/HrXV3I
cK3lUpfshKur6x4YBeZmNHK8G2oszFOgDzzntfVWY1b/v5cfxT0BD6j9mlaGDwg9x0TR
5B8XLBQX3DLtP9IWTe2OzpViTMEkjI1gHB2M5KnnmtVfrhB5/D8X58ZWy7vTDBxF9D9d
bycH1s12Ltw9qEpqaqJFQxWwu1AyjrFt1aRg9X6cTZcXBEZ8Ko1DEALs+m9t7nspLzGS
0ncQ==
X-Gm-Message-State: AMke39k4ocPmSRoPC5PttmX3JNRG8r4bbRPyNhB/3srLcxApVF4/+PxbOCLii9PyR+f7ZoNi
X-Received: by 10.28.128.131 with SMTP id b125mr2084358wmd.7.1487932979388;
Fri, 24 Feb 2017 02:42:59 -0800 (PST)
Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr.
[2a01:cb0c:3c6:5100:226:b0ff:feed:2fc])
by smtp.gmail.com with ESMTPSA id 63sm9830711wrh.68.2017.02.24.02.42.58
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 24 Feb 2017 02:42:59 -0800 (PST)
Date: Fri, 24 Feb 2017 11:42:56 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: "fengtian Guo" <fengtian.guo@6wind.com>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
"Zhang, Helin" <helin.zhang@intel.com>, "Ananyev, Konstantin"
<konstantin.ananyev@intel.com>, "stable@dpdk.org" <stable@dpdk.org>, "David
Marchand" <david.marchand@6wind.com>
Message-ID: <20170224114256.186222f0@platinum>
In-Reply-To: <tencent_0F0029B4681AECF920B4A038@qq.com>
References: <1484153524-19337-1-git-send-email-olivier.matz@6wind.com>
<6A0DE07E22DDAD4C9103DF62FEBC09093B56823A@shsmsx102.ccr.corp.intel.com>
<tencent_276E3C246D48DB0F50F825C9@qq.com>
<6A0DE07E22DDAD4C9103DF62FEBC09093B56833D@shsmsx102.ccr.corp.intel.com>
<tencent_0F0029B4681AECF920B4A038@qq.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dpdk-dev] [PATCH] net/ixgbevf: reset hardware whenstoppingport
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2017 10:43:00 -0000
Hi Fengtian,
On Fri, 24 Feb 2017 18:15:27 +0800, "fengtian Guo"
<fengtian.guo@6wind.com> wrote:
> Hi, Wenzhuo
>=20
> The attachment is test report without product.
The test report uses is a use-case with 6WINDGate, so it cannot be
reproduced by Intel guys.
I'll see how to reproduce the same case with testpmd and send an
update.
Thanks,
Olivier
>=20
> =20
> ------------------ Original ------------------
> From: "Lu, Wenzhuo"<wenzhuo.lu@intel.com>;
> Date: Fri, Feb 24, 2017 04:54 PM
> To: "fengtian Guo"<fengtian.guo@6wind.com>; "Olivier
> Matz"<olivier.matz@6wind.com>; "dev@dpdk.org"<dev@dpdk.org>; "Zhang,
> Helin"<helin.zhang@intel.com>; "Ananyev,
> Konstantin"<konstantin.ananyev@intel.com>; Cc:
> "stable@dpdk.org"<stable@dpdk.org>; "David
> Marchand"<david.marchand@6wind.com>; Subject: RE: Re:RE: [dpdk-dev]
> [PATCH] net/ixgbevf: reset hardware whenstoppingport
>=20
> =20
> =20
> Hi Fengtian,
> =20
> Would you like to let us know how you validate this patch? As I=E2=80=99ve
> tried just stop -> start VF can make it work again after PF down ->
> up. Thanks.=20
> =20
> =20
> =20
> From: fengtian.guo@6wind.com.cn [mailto:fengtian.guo@6wind.com.cn] On
> Behalf Of fengtian Guo Sent: Friday, February 24, 2017 4:47 PM
> To: Lu, Wenzhuo; Olivier Matz; dev@dpdk.org; Zhang, Helin; Ananyev,
> Konstantin Cc: stable@dpdk.org; David Marchand
> Subject: Re:RE: [dpdk-dev] [PATCH] net/ixgbevf: reset hardware when
> stoppingport=20
> =20
> =20
> =20
> =20
> Hi, Wenzhuo
> =20
> Sorry, Now I just notice the email is related with me.
> =20
> > Seems the commit log doesn't match the code change.
> > This change cannot resolve the described problem. The problem is
> > VF doesn't handle the PF reset event. Moving the hw_reset from
> > close to stop doesn't help and not necessary. Because PF has
> > already reset VF stuff during resetting itself, that's why VF not
> > working anymore. =20
> =20
> Explain the problem of this issue.
> 1) it seems VF have to call ixgbe_reset_hw() when it receive PF
> reset event. it seems VF is client and PF is server and VF has to
> reset the register on his side, after PF has reset the register on
> his side. 2) with this patch, when VF receive the event after PF is
> set link down, it will call ixgbe_reset_hw() in ixgbevf_dev_close().
> and we have validate this patch=20
> =20
> Thanks
> Fengtian
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> ------------------ Original ------------------
> =20
> =20
> From: "Lu, Wenzhuo"<wenzhuo.lu@intel.com>;
> =20
> =20
> Date: Fri, Feb 24, 2017 01:21 PM
> =20
> =20
> To: "Olivier Matz"<olivier.matz@6wind.com>;
> "dev@dpdk.org"<dev@dpdk.org>; "Zhang, Helin"<helin.zhang@intel.com>;
> "Ananyev, Konstantin"<konstantin.ananyev@intel.com>;=20
> Cc: "Guo Fengtian"<fengtian.guo@6wind.com>;
> "stable@dpdk.org"<stable@dpdk.org>; "David
> Marchand"<david.marchand@6wind.com>;=20
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbevf: reset hardware when
> stoppingport=20
> =20
> =20
> =20
> =20
> =20
> Hi Olivier, Fengtian,
> =20
> =20
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > Sent: Thursday, January 12, 2017 12:52 AM
> > To: dev@dpdk.org; Zhang, Helin; Ananyev, Konstantin
> > Cc: Guo Fengtian; stable@dpdk.org; David Marchand
> > Subject: [dpdk-dev] [PATCH] net/ixgbevf: reset hardware when
> > stopping port
> >=20
> > From: Guo Fengtian <fengtian.guo@6wind.com>
> >=20
> > When PF triggers a reset, VF port must acknowledge it by calling
> > ixgbe_reset_hw().
> >=20
> > Before this patch, the port link status, speed and duplex are
> > invalid (all set to 0).
> >=20
> > The patch move the call to ixgbe_reset_hw() from
> > ixgbevf_dev_close() to ixgbevf_dev_stop(), so that after a port
> > restart on the VM, the link status is properly marked down, with
> > correct speed and duplex.
> >=20
> > Fixes: f0160874c041 ("ixgbe: various updates")
> >=20
> > CC: stable@dpdk.org
> > Signed-off-by: Guo Fengtian <fengtian.guo@6wind.com>
> > Signed-off-by: David Marchand <david.marchand@6wind.com>
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > ---
> >=20
> > Hi,
> >=20
> > The use case for this problem was described some time ago, see:
> > http://dpdk.org/ml/archives/dev/2015-December/030067.html
> >=20
> > It is also part of 2.2 release note:
> > http://dpdk.org/browse/dpdk/tree/doc/guides/rel_notes/release_2_2.rst=
#n4
> > 71
> >=20
> > Regards,
> > Olivier =20
> Seems the commit log doesn't match the code change.
> This change cannot resolve the described problem. The problem is VF
> doesn't handle the PF reset event. Moving the hw_reset from close to
> stop doesn't help and not necessary. Because PF has already reset VF
> stuff during resetting itself, that's why VF not working anymore.=20
> >=20
> >=20
> > drivers/net/ixgbe/ixgbe_ethdev.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >=20
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index b7ddd4f..2d8641a 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -4268,6 +4268,7 @@ ixgbevf_dev_stop(struct rte_eth_dev *dev)
> > PMD_INIT_FUNC_TRACE();
> >=20
> > ixgbevf_intr_disable(hw);
> > + ixgbe_reset_hw(hw);
> >=20
> > hw->adapter_stopped =3D 1;
> > ixgbe_stop_adapter(hw);
> > @@ -4294,12 +4295,8 @@ ixgbevf_dev_stop(struct rte_eth_dev *dev)
> > static void ixgbevf_dev_close(struct rte_eth_dev *dev) {
> > - struct ixgbe_hw *hw =3D IXGBE_DEV_PRIVATE_TO_HW(dev->data- =20
> > >dev_private); =20
> > -
> > PMD_INIT_FUNC_TRACE();
> >=20
> > - ixgbe_reset_hw(hw);
> > -
> > ixgbevf_dev_stop(dev);
> >=20
> > ixgbe_dev_free_queues(dev);
> > --
> > 2.8. =20