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 6E96AA04B5; Mon, 11 Jan 2021 10:06:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9076140CBA; Mon, 11 Jan 2021 10:06:29 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id AA6E4140CB8; Mon, 11 Jan 2021 10:06:27 +0100 (CET) IronPort-SDR: +fbe0OQq/baTKktRQJvu00N6wcZh363aBNspYT6+osipQeMIQ0jL2SIe25gg+6hnmTgSh0gQCV DtoETnuDBphQ== X-IronPort-AV: E=McAfee;i="6000,8403,9860"; a="239371032" X-IronPort-AV: E=Sophos;i="5.79,338,1602572400"; d="scan'208";a="239371032" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2021 01:06:26 -0800 IronPort-SDR: f34C27sC9tJyPem2jw6mS2psuo5lRUCRS0zj+4zny3tr4iA6Y4s4pieJ4sLsKHm0tQFwu1arub fyadkGl7vG8g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,338,1602572400"; d="scan'208";a="348052507" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga003.jf.intel.com with ESMTP; 11 Jan 2021 01:06:25 -0800 Received: from shsmsx604.ccr.corp.intel.com (10.109.6.214) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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 01:06:24 -0800 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by SHSMSX604.ccr.corp.intel.com (10.109.6.214) 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 17:06:23 +0800 Received: from shsmsx606.ccr.corp.intel.com ([10.109.6.216]) by SHSMSX606.ccr.corp.intel.com ([10.109.6.216]) with mapi id 15.01.1713.004; Mon, 11 Jan 2021 17:06:22 +0800 From: "Xie, WeiX" To: "Yu, DapengX" , "Zhang, Qi Z" , "Wu, Jingjing" , "Xing, Beilei" , "Xu, Ting" CC: "dev@dpdk.org" , "Yu, DapengX" , "stable@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] net/iavf: fix vector id assignment Thread-Index: AQHW3nihF7otXA6j5kSOZSbz8idYz6odDOuAgAUk0wA= Date: Mon, 11 Jan 2021 09:06:22 +0000 Message-ID: <61168144445b48d3b4f0df77ce88650a@intel.com> References: <20201230065347.90115-1-dapengx.yu@intel.com> <20210108102111.7519-1-dapengx.yu@intel.com> In-Reply-To: <20210108102111.7519-1-dapengx.yu@intel.com> 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" Tested-by: Xie,WeiX < weix.xie@intel.com> Regards, Xie Wei > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of > dapengx.yu@intel.com > Sent: Friday, January 8, 2021 6:21 PM > To: Zhang, Qi Z ; Wu, Jingjing > ; Xing, Beilei ; Xu, Ting > > Cc: dev@dpdk.org; Yu, DapengX ; stable@dpdk.org > Subject: [dpdk-dev] [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 > number of available MSI-X interrupts per VF - 1 (the 1 is for miscellaneo= us > interrupt) and the number of configured Rx queues. > The current code break the rule because the number of available MSI-X > 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. So = each > queue can be assigned a unique vector_id. >=20 > For example: 17 available MSI-X interrupts, and 16 available Rx queues pe= r 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 Rx > queue3. >=20 > Current code breaks the rule in this normal situation, because when assig= n > 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 cond= ition > used causes vector_id wrap around too early. >=20 > In iavf_config_irq_map(), the current code does not write data into the l= ast > element of vecmap[], because of the previous code break. Which cause > wrong data is sent to PF with opcode 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 queues = can > be assigned same vector_id. >=20 > In order to adapt to large VFs and avoid wrapping early, the condition 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 b/drivers/net/iavf/iavf_ethde= v.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 > rte_eth_dev *dev, > struct iavf_qv_map *qv_map; > uint16_t interval, i; > 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 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 i; > qv_map[i].vector_id =3D vec; > intr_handle->intr_vec[i] =3D vec++; > - if (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