From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 77766A00BE; Tue, 29 Oct 2019 08:47:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7D8B81BED4; Tue, 29 Oct 2019 08:47:33 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id C578DCF3 for ; Tue, 29 Oct 2019 08:47:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572335251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fdIuphtRz+D+MjR/5tdhNXEJgTo9Lr+Y/BKPC6ZHlQs=; b=eoWb4bjQjeq0cyi9ktvqNJv6b/f7/JKGhRbptxv7dXmun/zf56m09lwwGzENmMjwNSbX9L TF6PI77JHg+7XjYlf7xQut6GT0NAEw4mvfgvuJ7FhjqUxAE89rCBZWFFsRtqzNIObbk9rc afPxj3LoKWAk78bGgIt2eR5MGmqjQ24= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-356-okV3vh4lMa2OgWecBc0lkQ-1; Tue, 29 Oct 2019 03:47:28 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CF64F8017DD; Tue, 29 Oct 2019 07:47:26 +0000 (UTC) Received: from [10.36.116.152] (ovpn-116-152.ams2.redhat.com [10.36.116.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9B9C60874; Tue, 29 Oct 2019 07:47:25 +0000 (UTC) From: "Eelco Chaudron" To: "Zhang, Xiao" , "Xing, Beilei" Cc: "Zhang, Qi Z" , dev@dpdk.org Date: Tue, 29 Oct 2019 08:47:24 +0100 Message-ID: <63F37687-13EA-426A-A23D-301EE6CB65F0@redhat.com> In-Reply-To: References: <675a204e3f5630d66cfa79b933da25a6c9227069.1568705792.git.echaudro@redhat.com> <94479800C636CB44BD422CB454846E013CE63719@SHSMSX101.ccr.corp.intel.com> <65C73CA4-E1AA-44F2-9258-586B23CC1448@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: okV3vh4lMa2OgWecBc0lkQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state after VF reset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 29 Oct 2019, at 8:39, Zhang, Xiao wrote: >> -----Original Message----- >> From: Eelco Chaudron >> Sent: Friday, October 25, 2019 5:24 PM >> To: Xing, Beilei ; Zhang, Xiao=20 >> >> Cc: Zhang, Qi Z ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state=20 >> after VF >> reset >> >> >> >> On 17 Oct 2019, at 8:34, Xing, Beilei wrote: >> >>>> On 17 Sep 2019, at 9:40, Eelco Chaudron wrote: >>>> >>>>> Even though the device reset is successful, disabling promiscuous >>>>> mode might not always succeed, causing enabling it after reset to >>>>> fail. >>>>> This would happen when the kernel driver requires a reset of the=20 >>>>> VF. >>>>> >>>>> This patch resets the internal state, so next time promiscuous=20 >>>>> mode >>>>> is configured it will be enabled. >>>>> >>>>> Signed-off-by: Eelco Chaudron >>>>> --- >>>>> drivers/net/i40e/i40e_ethdev_vf.c | 10 ++++++++++ >>>>> 1 file changed, 10 insertions(+) >>>>> >>>>> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c >>>>> b/drivers/net/i40e/i40e_ethdev_vf.c >>>>> index 551f6fa..e0f99a4 100644 >>>>> --- a/drivers/net/i40e/i40e_ethdev_vf.c >>>>> +++ b/drivers/net/i40e/i40e_ethdev_vf.c >>>>> @@ -2276,11 +2276,21 @@ static int eth_i40evf_pci_remove(struct >>>>> rte_pci_device *pci_dev) i40evf_dev_reset(struct rte_eth_dev=20 >>>>> *dev) >>>>> { >>>>> =09int ret; >>>>> +=09struct i40e_vf *vf =3D >>>>> I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private); >>>>> >>>>> =09ret =3D i40evf_dev_uninit(dev); >>>>> =09if (ret) >>>>> =09=09return ret; >>>>> >>>>> +=09/* >>>>> +=09 * Even though the device reset is successful disabling >>>>> promiscuous >>>>> +=09 * mode might not always succeed, causing enabling it after=20 >>>>> reset >>>>> to >>> >>> I think we need to root cause why fail to disable promiscuous mode=20 >>> and >>> try to fix it first. >> >> I=E2=80=99ve copied in Xiao who helped me identify the issue in your=20 >> driver. >> >> The issue is because the change from kernel pf was not synced to DPDK=20 >> vf during >> the closing period of reset, so we get this failure. Xiao can you add=20 >> more details? >> > > The root cause is when kernel pf generate DPDK vf reset event, the=20 > flag > vf->promisc_unicast_enabled will not be cleared but promiscuous mode=20 > is > disabled. When trying to enable promiscuous mode next time by calling > i40evf_dev_promiscuous_enable won't work because it will check the > vf->promisc_unicast_enabled flag first. > > static int > i40evf_dev_promiscuous_enable(struct rte_eth_dev *dev) > { > ... > /* If enabled, just return */ > if (vf->promisc_unicast_enabled) > return 0; > ... > } > > Hi Eelco, > > I think you may need add more detailed message in the commit log or=20 > comments. My interpretation of the request was that Beilei wanted to know why=20 disabling promiscuous mode in HW was failing. Beilei can you comment, is=20 the additional description from Xiao enough? >> >>>>> +=09 * fail. This would happen when the kernel driver requires a=20 >>>>> reset >>>>> +=09 * of the VF. >>>>> +=09 */ >>>>> +=09if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) >>>>> +=09=09vf->promisc_unicast_enabled =3D FALSE; >>>>> + >>>>> =09ret =3D i40evf_dev_init(dev); >>>>> >>>>> =09return ret; >>>>> -- >>>>> 1.8.3.1