From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0016ce01.pphosted.com (mx0b-0016ce01.pphosted.com [67.231.156.153]) by dpdk.org (Postfix) with ESMTP id 8FC612C23 for ; Mon, 27 Feb 2017 08:52:26 +0100 (CET) Received: from pps.filterd (m0085408.ppops.net [127.0.0.1]) by mx0b-0016ce01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1R7qEVo008338; Sun, 26 Feb 2017 23:52:24 -0800 Received: from avcashub1.qlogic.com ([198.186.0.117]) by mx0b-0016ce01.pphosted.com with ESMTP id 28ut281und-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Feb 2017 23:52:24 -0800 Received: from avluser05.qlc.com (10.1.113.115) by qlc.com (10.1.4.192) with Microsoft SMTP Server id 14.3.235.1; Sun, 26 Feb 2017 23:52:23 -0800 Received: (from rmody@localhost) by avluser05.qlc.com (8.14.4/8.14.4/Submit) id v1R7qNPY009738; Sun, 26 Feb 2017 23:52:23 -0800 X-Authentication-Warning: avluser05.qlc.com: rmody set sender to rasesh.mody@cavium.com using -f From: Rasesh Mody To: CC: Rasesh Mody , Date: Sun, 26 Feb 2017 23:51:58 -0800 Message-ID: <1488181923-9649-16-git-send-email-rasesh.mody@cavium.com> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1488181923-9649-1-git-send-email-rasesh.mody@cavium.com> References: <1488181923-9649-1-git-send-email-rasesh.mody@cavium.com> MIME-Version: 1.0 Content-Type: text/plain disclaimer: bypass X-Proofpoint-Virus-Version: vendor=nai engine=5800 definitions=8451 signatures=669242 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1702270080 Subject: [dpdk-dev] [PATCH 16/21] net/qede/base: fix first VF index calculation 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: , X-List-Received-Date: Mon, 27 Feb 2017 07:52:26 -0000 When a server doesn't support ARI, VF offsets begin at a much higher number. As a result, ecore miscalculates the first_vf_in_pf and initialization fails since base driver incorrectly learns there are no SBs for its VF [as its VFs are out of range]. Signed-off-by: Rasesh Mody --- drivers/net/qede/base/ecore_sriov.c | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/drivers/net/qede/base/ecore_sriov.c b/drivers/net/qede/base/ecore_sriov.c index e9a2421..6ca7b3c 100644 --- a/drivers/net/qede/base/ecore_sriov.c +++ b/drivers/net/qede/base/ecore_sriov.c @@ -601,14 +601,30 @@ enum _ecore_status_t ecore_iov_hw_info(struct ecore_hwfn *p_hwfn) return ECORE_SUCCESS; } - /* Calculate the first VF index - this is a bit tricky; Basically, - * VFs start at offset 16 relative to PF0, and 2nd engine VFs begin - * after the first engine's VFs. + /* First VF index based on offset is tricky: + * - If ARI is supported [likely], offset - (16 - pf_id) would + * provide the number for eng0. 2nd engine Vfs would begin + * after the first engine's VFs. + * - If !ARI, VFs would start on next device. + * so offset - (256 - pf_id) would provide the number. + * Utilize the fact that (256 - pf_id) is achieved only be later + * to diffrentiate between the two. */ - p_dev->p_iov_info->first_vf_in_pf = p_hwfn->p_dev->p_iov_info->offset + - p_hwfn->abs_pf_id - 16; - if (ECORE_PATH_ID(p_hwfn)) - p_dev->p_iov_info->first_vf_in_pf -= MAX_NUM_VFS_BB; + + if (p_hwfn->p_dev->p_iov_info->offset < (256 - p_hwfn->abs_pf_id)) { + u32 first = p_hwfn->p_dev->p_iov_info->offset + + p_hwfn->abs_pf_id - 16; + + p_dev->p_iov_info->first_vf_in_pf = first; + + if (ECORE_PATH_ID(p_hwfn)) + p_dev->p_iov_info->first_vf_in_pf -= MAX_NUM_VFS_BB; + } else { + u32 first = p_hwfn->p_dev->p_iov_info->offset + + p_hwfn->abs_pf_id - 256; + + p_dev->p_iov_info->first_vf_in_pf = first; + } DP_VERBOSE(p_hwfn, ECORE_MSG_IOV, "First VF in hwfn 0x%08x\n", -- 1.7.10.3