From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id DF2C245B69;
Fri, 18 Oct 2024 16:39:01 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 696CD4066C;
Fri, 18 Oct 2024 16:38:50 +0200 (CEST)
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9])
by mails.dpdk.org (Postfix) with ESMTP id 948CF402DF
for <dev@dpdk.org>; Fri, 18 Oct 2024 16:38:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1729262323; x=1760798323;
h=from:to:cc:subject:date:message-id:in-reply-to:
references:mime-version:content-transfer-encoding;
bh=1OQ4Q4q+ZBJ5H4XxBbRWXrDkF1mNl1+P583z2lbgsa4=;
b=cOrnJxRxxfNjjCYXj5dIJRu3tGGdqWDbkg+5bT74+/gW6KbsQ0zcua/Q
ud9xsG79TG5ixU/UeGpqmQhFJDeR/8QXenFgjttlCa1vngum5fIBNKJqS
nJDoht616HOChw14F0RgnjHLZriW5K0e3fCZinxdXHr46iDRQYQ47+tTS
hlbngBSpj7qPb3XRICCbDcNvwRal4Km7yIYYALJyaCmDX0k9Yk2WUxe7F
lw8DrxdUZ/l3LYgsP8s/spAv1fu0h3NNzxZjZMj5tl4XH6hXWoz3Xx6zR
4J5h50TfIq97sNR/Lr1CSvekYLfw4np1UhEV/r6Ed2r4JZ0ExYhLWDdnv Q==;
X-CSE-ConnectionGUID: he57EjulRvaMhUD5I78/3w==
X-CSE-MsgGUID: gw8RACRwTkiZsxjWrWm+3g==
X-IronPort-AV: E=McAfee;i="6700,10204,11229"; a="39422209"
X-IronPort-AV: E=Sophos;i="6.11,214,1725346800"; d="scan'208";a="39422209"
Received: from fmviesa004.fm.intel.com ([10.60.135.144])
by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
18 Oct 2024 07:38:42 -0700
X-CSE-ConnectionGUID: pBoZ3v8CQ8WEkENvwOLW8g==
X-CSE-MsgGUID: NusjgnPyT0mT+uFDrk3XlQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.11,214,1725346800"; d="scan'208";a="83510954"
Received: from unknown (HELO silpixa00401385.ir.intel.com) ([10.237.214.25])
by fmviesa004.fm.intel.com with ESMTP; 18 Oct 2024 07:38:41 -0700
From: Bruce Richardson <bruce.richardson@intel.com>
To: dev@dpdk.org
Cc: Bruce Richardson <bruce.richardson@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: [PATCH v3 4/4] net/ice: limit the number of queues to sched
capabilities
Date: Fri, 18 Oct 2024 15:38:22 +0100
Message-ID: <20241018143822.2784548-5-bruce.richardson@intel.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241018143822.2784548-1-bruce.richardson@intel.com>
References: <20241009170822.344716-1-bruce.richardson@intel.com>
<20241018143822.2784548-1-bruce.richardson@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Rather than assuming that each VSI can hold up to 256 queue pairs,
or the reported device limit, query the available nodes in the scheduler
tree to check that we are not overflowing the limit for number of
child scheduling nodes at each level. Do this by multiplying
max_children for each level beyond the VSI and using that as an
additional cap on the number of queues.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/ice/ice_ethdev.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 97092c8550..d5e94a6685 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -915,7 +915,7 @@ ice_vsi_config_default_rss(struct ice_aqc_vsi_props *info)
}
static int
-ice_vsi_config_tc_queue_mapping(struct ice_vsi *vsi,
+ice_vsi_config_tc_queue_mapping(struct ice_hw *hw, struct ice_vsi *vsi,
struct ice_aqc_vsi_props *info,
uint8_t enabled_tcmap)
{
@@ -931,13 +931,28 @@ ice_vsi_config_tc_queue_mapping(struct ice_vsi *vsi,
}
/* vector 0 is reserved and 1 vector for ctrl vsi */
- if (vsi->adapter->hw.func_caps.common_cap.num_msix_vectors < 2)
+ if (vsi->adapter->hw.func_caps.common_cap.num_msix_vectors < 2) {
vsi->nb_qps = 0;
- else
+ } else {
vsi->nb_qps = RTE_MIN
((uint16_t)vsi->adapter->hw.func_caps.common_cap.num_msix_vectors - 2,
RTE_MIN(vsi->nb_qps, ICE_MAX_Q_PER_TC));
+ /* cap max QPs to what the HW reports as num-children for each layer.
+ * Multiply num_children for each layer from the entry_point layer to
+ * the qgroup, or second-last layer.
+ * Avoid any potential overflow by using uint32_t type and breaking loop
+ * once we have a number greater than the already configured max.
+ */
+ uint32_t max_sched_vsi_nodes = 1;
+ for (uint8_t i = hw->sw_entry_point_layer; i < hw->num_tx_sched_layers - 1; i++) {
+ max_sched_vsi_nodes *= hw->max_children[i];
+ if (max_sched_vsi_nodes >= vsi->nb_qps)
+ break;
+ }
+ vsi->nb_qps = RTE_MIN(vsi->nb_qps, max_sched_vsi_nodes);
+ }
+
/* nb_qps(hex) -> fls */
/* 0000 -> 0 */
/* 0001 -> 0 */
@@ -1709,7 +1724,7 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
rte_cpu_to_le_16(hw->func_caps.fd_fltr_best_effort);
/* Enable VLAN/UP trip */
- ret = ice_vsi_config_tc_queue_mapping(vsi,
+ ret = ice_vsi_config_tc_queue_mapping(hw, vsi,
&vsi_ctx.info,
ICE_DEFAULT_TCMAP);
if (ret) {
@@ -1733,7 +1748,7 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
vsi_ctx.info.fd_options = rte_cpu_to_le_16(cfg);
vsi_ctx.info.sw_id = hw->port_info->sw_id;
vsi_ctx.info.sw_flags2 = ICE_AQ_VSI_SW_FLAG_LAN_ENA;
- ret = ice_vsi_config_tc_queue_mapping(vsi,
+ ret = ice_vsi_config_tc_queue_mapping(hw, vsi,
&vsi_ctx.info,
ICE_DEFAULT_TCMAP);
if (ret) {
--
2.43.0