From nobody Sun Nov 24 11:39:22 2024 Received: from mail-oa1-f100.google.com (mail-oa1-f100.google.com [209.85.160.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 696C017BEB7 for ; Tue, 5 Nov 2024 20:41:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.100 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730839320; cv=none; b=MgdsukSwTQ+zrEMxVDGY4+HiK6NcvN+9X8QAm76E955Ci7obaeYlsMYH7k5ZWgre2EAi13ttCdK37QiyBfT+vhx5q2SJpklP0+pp6w7IDcqBbxfzG8rx91rmdIf1+gDm3jnUvRiC17TkryQoieHIb4ns3RZFkNtcZ7ORGhvOskk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730839320; c=relaxed/simple; bh=fWkWu0fGnyaGjA6B6hCOd4KCPCNJ21ri/TvOuUXtMk4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fcFg9pCAxv4zt0IqA/aAoWHYR+9CtaEzKwxnwmjMd6FKpRN1HC8AsC2r91YMo9DjugrSYtuTPLVsQmQYEuUuwQMXukwzuYZITaVSgnYMfWTnhOmXB0t3U2orUM4yWsBrA0HXVDo1wS57Ni975G0JrLynATK7cu/9TaC1t17WOPE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com; spf=fail smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=RNClhGVh; arc=none smtp.client-ip=209.85.160.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=purestorage.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="RNClhGVh" Received: by mail-oa1-f100.google.com with SMTP id 586e51a60fabf-28889dcca4dso387497fac.2 for ; Tue, 05 Nov 2024 12:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1730839317; x=1731444117; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3D9gC9tIydtY1uqE/NToJTfUA9D/ImLOp+4hoaGi+fk=; b=RNClhGVhKTkFG284ltAEZ1+0yCKk677iTVW0oxwpqOmV6byluSW6/Idc1z2dPhEM58 izIUB5qukkq7rSmjb4Q2URaAO9xqABn9rYX3cXDVzPszANQyAY8esOu+kFMYXE27qX7e APaSGXIzHTkVkK4AhVM094UQ+sCCwpFEPFyJ5EYdSQWOGA3X47bp2QyIU2bWJMMcRTE7 20CiFr8DnYQgKsGpCsPIaEC3+YJYvy4T91OGKmSq1DG0XHXNyXOoR18x+3Vj/nyrkm3M k+5WXc8+Be/sFkHJv8dwzV2/m+eK/qN6Y45JND0wRsmSiT5dDVCrEFPHOPxMHxKGj1PK FS0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730839317; x=1731444117; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3D9gC9tIydtY1uqE/NToJTfUA9D/ImLOp+4hoaGi+fk=; b=kxzbzTUP8pFc8QxwGJ+CxOzz8TQwlUyrbico2JSM3ZNA4eFWhFgzzW73sJjjgjtvb8 FIkuO6Kr4wnAgFSS/KBlpCDGEa5uKtV+ar0lrBOXM12KQXlrFb3awGqtS2Sdh1ATC74q YtlfgsIpgI5ll5M3H0EWtltUJBkeRRdmBvxkxsZrWgTnGAM8JUA5Ga/Wl/tRELmcfoLE CudD5NVrfeaPu6SGBe1RiS8bQ5vefYjAGS3HkOanT2VLNZaHdU1bcxuxT0gcV8CLxJvo t7FxEl/ajMHpGts7n4ZbwjTwf1P7ZT3P6aPW6R6jHKGLcRpZH4H6EWDMP+uNlPd/tpuB 082A== X-Forwarded-Encrypted: i=1; AJvYcCVjmqSb14FFCScFNhJStU40t5Y0M9reDK5hTPkK1qsIxFaBEHyXOR4ZGLw6V8Nhjcwk6OhArjymNYhJByI=@vger.kernel.org X-Gm-Message-State: AOJu0YxkijSMOM4uxBVKFmbs4lPkkIGBEpD+oLPYSmlPoPlPtBib1m+a GROm5cwYwQ56gDJY/nH/vtoWRsY7LOP0+tmvQzsKebMAhUvoT/me2d3r3TYB0hyfAegcwbGZeXE fwSTh4iYSa1rMYUsT+zbMnHvC1pINWnfc4cRk5p2Vm6k8W2Rl X-Google-Smtp-Source: AGHT+IFFj+NXeyBVIJKuxXoFbm0U0klEMjzpvgGDAfmphm1s5cKOzarMplbtCNgb3hGFDYekjGbsr+xQxXZk X-Received: by 2002:a05:6830:600a:b0:710:f408:bd54 with SMTP id 46e09a7af769-71867f1a3b3mr10416111a34.2.1730839317543; Tue, 05 Nov 2024 12:41:57 -0800 (PST) Received: from c7-smtp-2023.dev.purestorage.com ([2620:125:9017:12:36:3:5:0]) by smtp-relay.gmail.com with ESMTPS id 006d021491bc7-5ec705a2446sm411582eaf.18.2024.11.05.12.41.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2024 12:41:57 -0800 (PST) X-Relaying-Domain: purestorage.com Received: from dev-csander.dev.purestorage.com (dev-csander.dev.purestorage.com [10.7.70.37]) by c7-smtp-2023.dev.purestorage.com (Postfix) with ESMTP id 67E67340245; Tue, 5 Nov 2024 13:41:56 -0700 (MST) Received: by dev-csander.dev.purestorage.com (Postfix, from userid 1557716354) id 5D637E42752; Tue, 5 Nov 2024 13:41:26 -0700 (MST) From: Caleb Sander Mateos To: Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Caleb Sander Mateos , Parav Pandit , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next v4] mlx5/core: Schedule EQ comp tasklet only if necessary Date: Tue, 5 Nov 2024 13:39:59 -0700 Message-ID: <20241105204000.1807095-1-csander@purestorage.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, the mlx5_eq_comp_int() interrupt handler schedules a tasklet to call mlx5_cq_tasklet_cb() if it processes any completions. For CQs whose completions don't need to be processed in tasklet context, this adds unnecessary overhead. In a heavy TCP workload, we see 4% of CPU time spent on the tasklet_trylock() in tasklet_action_common(), with a smaller amount spent on the atomic operations in tasklet_schedule(), tasklet_clear_sched(), and locking the spinlock in mlx5_cq_tasklet_cb(). TCP completions are handled by mlx5e_completion_event(), which schedules NAPI to poll the queue, so they don't need tasklet processing. Schedule the tasklet in mlx5_add_cq_to_tasklet() instead to avoid this overhead. mlx5_add_cq_to_tasklet() is responsible for enqueuing the CQs to be processed in tasklet context, so it can schedule the tasklet. CQs that need tasklet processing have their interrupt comp handler set to mlx5_add_cq_to_tasklet(), so they will schedule the tasklet. CQs that don't need tasklet processing won't schedule the tasklet. To avoid scheduling the tasklet multiple times during the same interrupt, only schedule the tasklet in mlx5_add_cq_to_tasklet() if the tasklet work queue was empty before the new CQ was pushed to it. The additional branch in mlx5_add_cq_to_tasklet(), called for each EQE, may add a small cost for the userspace Infiniband CQs whose completions are processed in tasklet context. But this seems worth it to avoid the tasklet overhead for CQs that don't need it. Note that the mlx4 driver works the same way: it schedules the tasklet in mlx4_add_cq_to_tasklet() and only if the work queue was empty before. Signed-off-by: Caleb Sander Mateos Reviewed-by: Parav Pandit Acked-by: Tariq Toukan Acked-by: Saeed Mahameed --- v4: add comment describing tasklet schedule condition v3: revise commit message v2: reorder variable declarations, describe CPU profile results drivers/net/ethernet/mellanox/mlx5/core/cq.c | 11 +++++++++++ drivers/net/ethernet/mellanox/mlx5/core/eq.c | 5 +---- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cq.c b/drivers/net/eth= ernet/mellanox/mlx5/core/cq.c index 4caa1b6f40ba..1fd403713baf 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/cq.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/cq.c @@ -69,22 +69,33 @@ void mlx5_cq_tasklet_cb(struct tasklet_struct *t) static void mlx5_add_cq_to_tasklet(struct mlx5_core_cq *cq, struct mlx5_eqe *eqe) { unsigned long flags; struct mlx5_eq_tasklet *tasklet_ctx =3D cq->tasklet_ctx.priv; + bool schedule_tasklet =3D false; =20 spin_lock_irqsave(&tasklet_ctx->lock, flags); /* When migrating CQs between EQs will be implemented, please note * that you need to sync this point. It is possible that * while migrating a CQ, completions on the old EQs could * still arrive. */ if (list_empty_careful(&cq->tasklet_ctx.list)) { mlx5_cq_hold(cq); + /* If the tasklet CQ work list isn't empty, mlx5_cq_tasklet_cb() + * is scheduled/running and hasn't processed the list yet, so it + * will see this added CQ when it runs. If the list is empty, + * the tasklet needs to be scheduled to pick up the CQ. The + * spinlock avoids any race with the tasklet accessing the list. + */ + schedule_tasklet =3D list_empty(&tasklet_ctx->list); list_add_tail(&cq->tasklet_ctx.list, &tasklet_ctx->list); } spin_unlock_irqrestore(&tasklet_ctx->lock, flags); + + if (schedule_tasklet) + tasklet_schedule(&tasklet_ctx->task); } =20 /* Callers must verify outbox status in case of err */ int mlx5_create_cq(struct mlx5_core_dev *dev, struct mlx5_core_cq *cq, u32 *in, int inlen, u32 *out, int outlen) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/eth= ernet/mellanox/mlx5/core/eq.c index 859dcf09b770..3fd2091c11c8 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c @@ -112,14 +112,14 @@ static int mlx5_eq_comp_int(struct notifier_block *nb, struct mlx5_eq_comp *eq_comp =3D container_of(nb, struct mlx5_eq_comp, irq_nb); struct mlx5_eq *eq =3D &eq_comp->core; struct mlx5_eqe *eqe; int num_eqes =3D 0; - u32 cqn =3D -1; =20 while ((eqe =3D next_eqe_sw(eq))) { struct mlx5_core_cq *cq; + u32 cqn; =20 /* Make sure we read EQ entry contents after we've * checked the ownership bit. */ dma_rmb(); @@ -142,13 +142,10 @@ static int mlx5_eq_comp_int(struct notifier_block *nb, break; } =20 eq_update_ci(eq, 1); =20 - if (cqn !=3D -1) - tasklet_schedule(&eq_comp->tasklet_ctx.task); - return 0; } =20 /* Some architectures don't latch interrupts when they are disabled, so us= ing * mlx5_eq_poll_irq_disabled could end up losing interrupts while trying to --=20 2.45.2