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 A7B4EA04B9; Mon, 11 Nov 2019 14:59:48 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 03E45237; Mon, 11 Nov 2019 14:59:48 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 6FB3091 for ; Mon, 11 Nov 2019 14:59:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573480785; 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=Vq16oAyV1OSbIEahTKNhhOAL1l0iSFD5kJSPpiahD+k=; b=H4/e9C2ePdB2zKPoAOWx2iOEeXNYU/HC9eqKyDtBmLoe1FwO/3DgLqLiPLdLrP47v4sB+7 yPMzZEYG5V4B58nPdws7YVet4JuL/OAPaxV8fXYENDOdTSt7dSixcEdakVtxfDHX9na37e Lwx1tdoBNJbDZeWlHObGodyu3o8BDAE= 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-293-ax_I2t7dNMWO96IJN8ds0w-1; Mon, 11 Nov 2019 08:59:42 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CEF238C4B86; Mon, 11 Nov 2019 13:59:41 +0000 (UTC) Received: from [10.36.116.242] (ovpn-116-242.ams2.redhat.com [10.36.116.242]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 075B65DD73; Mon, 11 Nov 2019 13:59:40 +0000 (UTC) From: "Eelco Chaudron" To: "Zhang, Xiao" Cc: "Zhang, Qi Z" , dev@dpdk.org, "Xing, Beilei" Date: Mon, 11 Nov 2019 14:59:39 +0100 Message-ID: <08143075-3803-4665-B916-3BA894FAE2AA@redhat.com> In-Reply-To: <724A0BBE-66F4-40D3-A38E-8F4E9C09ECC5@redhat.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> <724A0BBE-66F4-40D3-A38E-8F4E9C09ECC5@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: ax_I2t7dNMWO96IJN8ds0w-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 9:12, Eelco Chaudron wrote: >>>>>>>> >>>>>>>> +=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=20 >>>>>> 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=20 >>>> 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=20 >>> comment, 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=20 >> mode first. >> This patch looks like a workaround but not a fix. >> > > This was debugged together with Xiao and from what I understand is=20 > that DPDK fails to reset promiscuous mode in hardware as PF and VF=20 > operations are not synced between kernel and DPDK. > > Xiao told me this could not be fixed in another way, Xiao can you=20 > comment? > Xiao any update you can add to this so it=E2=80=99s more clear for Beilei? Thanks, Eelco