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 9D341A32A2 for ; Fri, 25 Oct 2019 11:24:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0A2731D158; Fri, 25 Oct 2019 11:24:08 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 69EFB1C0C8 for ; Fri, 25 Oct 2019 11:24:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571995446; 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=U/L/fDQXUUoH5TCiVZAIXV7QZnGHedvbJK8Y4g9ec/8=; b=AizeOgI3p9t6Y1C4Hh6gOkVs2fGgae+ww2ZiMRq1R1rK6gDTJc8BRSwNFrRinWFyLbWH/R 9lFzQICVK+Vso7sybwX1NCbRmOPjIV9DojYYV9dKwRliZEqt+zyzGBfcHaL8QFkEuPeuWF XoZr3lYFuu5cAWmQl0MpAIM+lLNyhmQ= 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-251-N8VerYBgPxCCt0M2yAp8bA-1; Fri, 25 Oct 2019 05:24:02 -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 07F481800DFB; Fri, 25 Oct 2019 09:24:01 +0000 (UTC) Received: from [10.36.116.168] (ovpn-116-168.ams2.redhat.com [10.36.116.168]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3156860852; Fri, 25 Oct 2019 09:24:00 +0000 (UTC) From: "Eelco Chaudron" To: "Xing, Beilei" , "Zhang, Xiao" Cc: "Zhang, Qi Z" , dev@dpdk.org Date: Fri, 25 Oct 2019 11:23:57 +0200 Message-ID: <65C73CA4-E1AA-44F2-9258-586B23CC1448@redhat.com> In-Reply-To: <94479800C636CB44BD422CB454846E013CE63719@SHSMSX101.ccr.corp.intel.com> References: <675a204e3f5630d66cfa79b933da25a6c9227069.1568705792.git.echaudro@redhat.com> <94479800C636CB44BD422CB454846E013CE63719@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: N8VerYBgPxCCt0M2yAp8bA-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 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=20 >>> mode >>> might not always succeed, causing enabling it after reset 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=20 >>> 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) =20 >>> { >>> =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=20 >>> promiscuous >>> +=09 * mode might not always succeed, causing enabling it after reset= =20 >>> to > > I think we need to root cause why fail to disable promiscuous mode and=20 > 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 DPDK vf=20 during the closing period of reset, so we get this failure. Xiao can you=20 add more details? >>> +=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