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 324B9A00BE; Fri, 1 Nov 2019 09:12:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 86CCB1D455; Fri, 1 Nov 2019 09:12:58 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 78D791D419 for ; Fri, 1 Nov 2019 09:12:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572595976; 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=kfAyRvBxy//V3M/gEpLcmCznjvcetyBT3uxBJhcCAvg=; b=dxREWFx7wrjJ5a8d2zwvNFNakY6B1Xf5AQdMo3bfeQOQw1IMzaEIhpzxlvwz55uyvtpsRX yLwYsVm4GGkXmZ3w5HXypjP7BCxamFDwxY6L5ZCKf2zi5zQcsEuBifHW9EcG+jO4xtVJEE qH0VZ9X4fZ8hCsU5Q4RWTz3LPvuWn0I= 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-31-pzP78ZQLOX-_zuXJj9S4Uw-1; Fri, 01 Nov 2019 04:12:55 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A0D10107ACC0; Fri, 1 Nov 2019 08:12:54 +0000 (UTC) Received: from [10.36.116.165] (ovpn-116-165.ams2.redhat.com [10.36.116.165]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9DD55600D1; Fri, 1 Nov 2019 08:12:53 +0000 (UTC) From: "Eelco Chaudron" To: "Xing, Beilei" , "Zhang, Xiao" Cc: "Zhang, Qi Z" , dev@dpdk.org Date: Fri, 01 Nov 2019 09:12:51 +0100 Message-ID: <724A0BBE-66F4-40D3-A38E-8F4E9C09ECC5@redhat.com> In-Reply-To: <94479800C636CB44BD422CB454846E013CE7E99B@SHSMSX101.ccr.corp.intel.com> References: <675a204e3f5630d66cfa79b933da25a6c9227069.1568705792.git.echaudro@redhat.com> <94479800C636CB44BD422CB454846E013CE63719@SHSMSX101.ccr.corp.intel.com> <65C73CA4-E1AA-44F2-9258-586B23CC1448@redhat.com> <63F37687-13EA-426A-A23D-301EE6CB65F0@redhat.com> <94479800C636CB44BD422CB454846E013CE7E99B@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: pzP78ZQLOX-_zuXJj9S4Uw-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 1 Nov 2019, at 3:38, Xing, Beilei wrote: >> -----Original Message----- >> From: Eelco Chaudron [mailto:echaudro@redhat.com] >> Sent: Tuesday, October 29, 2019 3:47 PM >> To: Zhang, Xiao ; Xing, Beilei=20 >> >> Cc: Zhang, Qi Z ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state=20 >> after VF >> reset >> >> >> >> 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 >>>> >>>> Cc: Zhang, Qi Z ; dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state >>>> 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=20 >>>>>>> promiscuous >>>>>>> mode might not always succeed, causing enabling it after reset=20 >>>>>>> to >>>>>>> fail. >>>>>>> This would happen when the kernel driver requires a reset of the >>>>>>> VF. >>>>>>> >>>>>>> This patch resets the internal state, so next time promiscuous >>>>>>> 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 >>>>>>> *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 >>>>>>> reset >>>>>>> to >>>>> >>>>> I think we need to root cause why fail to disable promiscuous mode >>>>> and >>>>> try to fix it first. >>>> >>>> I=E2=80=99ve copied in Xiao who helped me identify the issue in your >>>> driver. >>>> >>>> The issue is because the change from kernel pf was not synced to=20 >>>> DPDK >>>> vf during >>>> the closing period of reset, so we get this failure. Xiao can you=20 >>>> add >>>> more details? >>>> >>> >>> The root cause is when kernel pf generate DPDK vf reset event, the >>> flag >>> vf->promisc_unicast_enabled will not be cleared but promiscuous mode >>> is >>> disabled. When trying to enable promiscuous mode next time by=20 >>> 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 >>> comments. >> >> My interpretation of the request was that Beilei wanted to know why >> disabling promiscuous mode in HW was failing. Beilei can you comment,=20 >> is >> the additional description from Xiao enough? > > Yes, promisc_unicast_enabled flag is not cleared during vf reset=20 > because fail to disable promiscuous mode, > So I think we need to root cause why fail to disable promiscuous mode=20 > first. > This patch looks like a workaround but not a fix. > This was debugged together with Xiao and from what I understand is that=20 DPDK fails to reset promiscuous mode in hardware as PF and VF operations=20 are not synced between kernel and DPDK. Xiao told me this could not be fixed in another way, Xiao can you=20 comment? >> >>>> >>>>>>> +=09 * fail. This would happen when the kernel driver requires a >>>>>>> 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