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 DB867A04B5; Tue, 12 Jan 2021 07:46:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC43F140E8E; Tue, 12 Jan 2021 07:46:19 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 09E50140E7F; Tue, 12 Jan 2021 07:46:17 +0100 (CET) IronPort-SDR: 54XnZSZ/9BLvQDxORbH56jTi1qm731T3O3T1bSvyojtpg7RpEJY3lH8jX+gMeqpWMFdz0Pd0ZS FhVmfX2Yq7CQ== X-IronPort-AV: E=McAfee;i="6000,8403,9861"; a="239536110" X-IronPort-AV: E=Sophos;i="5.79,340,1602572400"; d="scan'208";a="239536110" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2021 22:46:16 -0800 IronPort-SDR: gCf2604YYFnQs66l95ac96+EbFRwvXTEUTAWhwdVfoRbelvLmyaaXDGDIeOy7j5eGieSWN6m8J KL2ognl1MJ6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,340,1602572400"; d="scan'208";a="569003443" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga006.fm.intel.com with ESMTP; 11 Jan 2021 22:46:16 -0800 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) 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.1713.5; Mon, 11 Jan 2021 22:46:13 -0800 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by SHSMSX603.ccr.corp.intel.com (10.109.6.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 12 Jan 2021 14:46:11 +0800 Received: from shsmsx603.ccr.corp.intel.com ([10.109.6.143]) by SHSMSX603.ccr.corp.intel.com ([10.109.6.143]) with mapi id 15.01.1713.004; Tue, 12 Jan 2021 14:46:11 +0800 From: "Yu, DapengX" To: "Xu, Ting" , "Zhang, Qi Z" , "Wu, Jingjing" , "Xing, Beilei" CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [PATCH] net/iavf: fix vector id assignment Thread-Index: AQHW3niNwiU9Aex5OkiIEAB/XvgsLaodDOuAgAYH3gCAAInyYA== Date: Tue, 12 Jan 2021 06:46:11 +0000 Message-ID: <9edafc3ba49446d898d298800b30ec78@intel.com> References: <20201230065347.90115-1-dapengx.yu@intel.com> <20210108102111.7519-1-dapengx.yu@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/iavf: fix vector id assignment X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Hi Ting, The following test case is for i40e. if you want to test the case on ice, j= ust ignore step 1.=20 Step1: switch i40evf to iavf # sed -i '/{ RTE_PCI_DEVICE(IAVF_INTEL_VENDOR_ID, IAVF_DEV_ID_ADAPTIVE_= VF) },/a { RTE_PCI_DEVICE(IAVF_INTEL_VENDOR_ID, IAVF_DEV_ID_VF) },' drivers= /net/iavf/iavf_ethdev.c # sed -i -e '/I40E_DEV_ID_VF/s/0x154C/0x164C/g' drivers/net/i40e/base/= i40e_devids.h # sed -i -e '/DEV_RX_OFFLOAD_CHECKSUM,/d' ./examples/l3fwd-power/main.c =20 Step2. build dpdk and l3fwd-power =20 Step3. create 1 vf # echo 1 > /sys/bus/pci/devices/0000\:81\:00.0/sriov_numvfs =20 Step4. bind vf to vfio-pci # usertools/dpdk-devbind.py --force --bind=3Dvfio-pci 81:02.0 =20 Step5. launch l3fwd-power # ./x86_64-native-linuxapp-gcc/examples/dpdk-l3fwd-power -l 0-1 -n 4 --= -P -p 0x1 --config=3D'(0,0,0),(0,1,1)' Expected result: start l3fwd-power successfully Actual result: fail to start l3fwd-power -----Original Message----- From: Xu, Ting=20 Sent: Tuesday, January 12, 2021 2:27 PM To: Yu, DapengX ; Zhang, Qi Z ;= Wu, Jingjing ; Xing, Beilei Cc: dev@dpdk.org; Yu, DapengX ; stable@dpdk.org Subject: RE: [PATCH] net/iavf: fix vector id assignment > -----Original Message----- > From: dapengx.yu@intel.com > Sent: Friday, January 8, 2021 6:21 PM > To: Zhang, Qi Z ; Wu, Jingjing=20 > ; Xing, Beilei ; Xu,=20 > Ting > Cc: dev@dpdk.org; Yu, DapengX ; stable@dpdk.org > Subject: [PATCH] net/iavf: fix vector id assignment >=20 > From: YU DAPENG >=20 > The number of MSI-X interrupts on Rx shall be the minimal value of the=20 > number of available MSI-X interrupts per VF - 1 (the 1 is for=20 > miscellaneous > interrupt) and the number of configured Rx queues. > The current code break the rule because the number of available MSI-X=20 > interrupts is used as the first value, but code does not subtract 1 from = it. >=20 > In normal situation, the first value is larger than the second value.=20 > So each queue can be assigned a unique vector_id. >=20 > For example: 17 available MSI-X interrupts, and 16 available Rx queues=20 > per VF; but only 4 Rx queues are configured when device is started. > vector_id:0 is for misc interrupt, vector_id:1 for Rx queue0, > vector_id:2 for Rx queue1, vector_id:3 for Rx queue2, vector_id:4 for=20 > Rx queue3. >=20 > Current code breaks the rule in this normal situation, because when=20 > assign vector_ids to interrupt handle, for example, it does not assign > vector_id:4 to the queue3, but assign vector_id:1 to it, because the=20 > condition used causes vector_id wrap around too early. >=20 Hi, Dapeng, Could you please further explain in which condition will this error happen?= Seems it requires vf->nb_msix =3D 3 to make it happen, but I do not notice= such situation. I know it may be an example, is there any more specific case? Thanks. > In iavf_config_irq_map(), the current code does not write data into=20 > the last element of vecmap[], because of the previous code break.=20 > Which cause wrong data is sent to PF with opcode=20 > VIRTCHNL_OP_CONFIG_IRQ_MAP and cause > error: VIRTCHNL_STATUS_ERR_PARAM(-5). >=20 > If kernel driver supports large VFs (up to 256 queues), different=20 > queues can be assigned same vector_id. >=20 > In order to adapt to large VFs and avoid wrapping early, the condition=20 > is replaced from vec >=3D vf->nb_msix to vec >=3D vf->vf_res->max_vectors= . >=20 > Fixes: d6bde6b5eae9 ("net/avf: enable Rx interrupt") > Cc: stable@dpdk.org >=20 > Signed-off-by: YU DAPENG > --- > drivers/net/iavf/iavf_ethdev.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/net/iavf/iavf_ethdev.c=20 > b/drivers/net/iavf/iavf_ethdev.c index 7e3c26a94..d730bb156 100644 > --- a/drivers/net/iavf/iavf_ethdev.c > +++ b/drivers/net/iavf/iavf_ethdev.c > @@ -483,6 +483,7 @@ static int iavf_config_rx_queues_irqs(struct=20 > rte_eth_dev *dev, struct iavf_qv_map *qv_map; uint16_t interval, i; =20 > int vec; > +uint16_t max_vectors; >=20 > if (rte_intr_cap_multiple(intr_handle) && > dev->data->dev_conf.intr_conf.rxq) { @@ -570,15 +571,16 @@ static=20 > int iavf_config_rx_queues_irqs(struct rte_eth_dev *dev, > /* If Rx interrupt is reuquired, and we can use > * multi interrupts, then the vec is from 1 > */ > -vf->nb_msix =3D RTE_MIN(vf->vf_res->max_vectors, > - intr_handle->nb_efd); > +max_vectors =3D > +vf->vf_res->max_vectors - > IAVF_RX_VEC_START; > +vf->nb_msix =3D RTE_MIN(max_vectors, intr_handle- > >nb_efd); > vf->msix_base =3D IAVF_RX_VEC_START; > vec =3D IAVF_RX_VEC_START; > for (i =3D 0; i < dev->data->nb_rx_queues; i++) { qv_map[i].queue_id = =3D=20 > i; qv_map[i].vector_id =3D vec; intr_handle->intr_vec[i] =3D vec++; -if= =20 > (vec >=3D vf->nb_msix) > +if (vec >=3D vf->vf_res->max_vectors) > vec =3D IAVF_RX_VEC_START; > } > vf->qv_map =3D qv_map; > -- > 2.27.0