From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1C655A050A for ; Sat, 7 May 2022 09:03:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E5F4F40395; Sat, 7 May 2022 09:03:37 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 2739A40395 for ; Sat, 7 May 2022 09:03:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651907016; x=1683443016; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ST/WpgO4k91p/eqPt24dhY3BAOg2uzs5ngMr7Lj86Z4=; b=VSaQzCj/dUmsKpWvwh9v94b9lG9pHcs6G72X5BvZUvlNCwexniPa6JEm 7NkFSSumogkKj+751y+WytWjr0utFRH0QuWpDd2Jdyb4LHRw47xXWjMpC sStruTKbRVn/6lSxgsMGyNETjVZM7JM/06Bmy1ugM0wiolf0f7+658BrU RRk4GABUSM13QH9ke6tGmne6QrxCXKCxi2AE8loODfsopghYwx3UXWLkF Rn4Y1yBMFkEZpX1tEbpo0Cz3b4UMfGDyYD7AKN6+b2VwQufYjSTezgvFl wKekCsKoNBAGm/d3IF79bCE2z6mCzmwA6UmgbKF3EQ9t8JHX0wkeNMc4e g==; X-IronPort-AV: E=McAfee;i="6400,9594,10339"; a="293881541" X-IronPort-AV: E=Sophos;i="5.91,206,1647327600"; d="scan'208";a="293881541" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2022 00:03:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,206,1647327600"; d="scan'208";a="538235563" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orsmga006.jf.intel.com with ESMTP; 07 May 2022 00:03:33 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Sat, 7 May 2022 00:03:32 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Sat, 7 May 2022 00:03:32 -0700 Received: from fmsmsx612.amr.corp.intel.com ([10.18.126.92]) by fmsmsx612.amr.corp.intel.com ([10.18.126.92]) with mapi id 15.01.2308.027; Sat, 7 May 2022 00:03:32 -0700 From: "Zhang, Qi Z" To: "Zhou, YidingX" , "Wu, Jingjing" , "Xing, Beilei" CC: "Yang, Qiming" , "stable@dpdk.org" , "Yeleswarapu, Ramamani" Subject: RE: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX descriptor Thread-Topic: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX descriptor Thread-Index: AQHYYbGy46ANB84hV0yBJDJqsDIB0a0Sqh2ggAChxoD//7EywA== Date: Sat, 7 May 2022 07:03:32 +0000 Message-ID: <7b75be77a604461d811332f8f5917a14@intel.com> References: <20220507093429.127530-1-yidingx.zhou@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org > -----Original Message----- > From: Zhou, YidingX > Sent: Saturday, May 7, 2022 12:43 PM > To: Zhang, Qi Z ; Wu, Jingjing ; > Xing, Beilei > Cc: Yang, Qiming ; stable@dpdk.org; Yeleswarapu, > Ramamani > Subject: RE: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX > descriptor >=20 >=20 >=20 > > -----Original Message----- > > From: Zhang, Qi Z > > Sent: Saturday, May 7, 2022 10:09 AM > > To: Zhou, YidingX ; Wu, Jingjing > > ; Xing, Beilei > > Cc: Yang, Qiming ; stable@dpdk.org; > > Yeleswarapu, Ramamani > > Subject: RE: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and > > RX descriptor > > > > > > > > > -----Original Message----- > > > From: Zhou, YidingX > > > Sent: Saturday, May 7, 2022 5:34 PM > > > To: Wu, Jingjing ; Xing, Beilei > > > > > > Cc: Yang, Qiming ; Zhang, Qi Z > > > ; stable@dpdk.org; Yeleswarapu, Ramamani > > > > > > Subject: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX > > > descriptor > > > > > > Some kernel drivers return the capability > > > VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC when > > IAVF_RXDID_COMMS_OVS_1 is not > > > supported. This causes PMD to use rx_pkt_burst that handles the Flex > > > Receive Descriptor format, but actually configures the RXDID into > > > IAVF_RXDID_LEGACY_1, then the fields of rte_mbuf Will be filled with > > > wrong values in rx_pkt_burst, which will eventually lead to coredump. > > > > > > This patch fixes mismatch between rx_pkt_burst and rx descriptor. > > > > > > Fixes: 12b435bf8f2f ("net/iavf: support flex desc metadata > > > extraction") > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Yiding Zhou > > > --- > > > drivers/net/iavf/iavf_rxtx.c | 20 ++++++++++++++------ > > > 1 file changed, 14 insertions(+), 6 deletions(-) > > > > > > diff --git a/drivers/net/iavf/iavf_rxtx.c > > > b/drivers/net/iavf/iavf_rxtx.c index 345f6aeebc..69584264de 100644 > > > --- a/drivers/net/iavf/iavf_rxtx.c > > > +++ b/drivers/net/iavf/iavf_rxtx.c > > > @@ -2908,6 +2908,18 @@ iavf_set_rx_function(struct rte_eth_dev *dev) > > > bool use_avx512 =3D false; bool use_flex =3D false; > > > > > > +if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC) > > > +use_flex =3D true; > > > > No need this check, we can init use_flex as true; > > >=20 > I'm not sure if use_flex can be init as true. is it possible that vf->vf_= res- > >vf_cap_flags doesn't contain VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC? I think the following loop will reset to false if any rxq->rxdid is legacy = or any unsupported rxdid happen Otherwise, it should always be true.=20 >=20 > > > + > > > +for (i =3D 0; i < dev->data->nb_rx_queues; i++) { rxq =3D > > > +dev->data->rx_queues[i]; if (rxq->rxdid <=3D IAVF_RXDID_LEGACY_1 || > > > +!(vf->supported_rxdid & BIT(rxq->rxdid))) { > > > > Check if rxq->rxdid is in supported list is not necessary, this has > > been guaranteed when we set it. > > >=20 > According to debugging, this is not guaranteed. > rxq->rxdid is set to IAVF_RXDID_COMMS_OVS_1 by default when vf- > >supported_rxdid =3D=3D 6 (just contains IAVF_RXDID_LEGACY_1 and > IAVF_RXDID_FLEX_NIC). OK, you can keep this. Btw, please send to dev@dpdk.org not stable@dpdk.org >=20 > > Also its better to print some warning message here, if we saw some > > rxq- > > >rxdid is flex and some rxq->rxdid is legacy as we have to set > > >rx_burst as > > legacy for all , this is something not be expected by user > > > > > Agreed, I will do this in v2. Thanks. >=20