From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792562867; b=uTWOESp6l8Zcm4o0e31LJUQ/yVS1FSuo6Ynzq13XByTQQjNB3cg5wKWXamtOzxLRdxpL yqnZCczQthTxVZW1mDfKJbPauYG+oijBvYn8X2v8KW22slDMhY4hiBkNHyR7cqB9bwMYg lPBshBxVXRzmKBwnK77fLXsjDl3zVuNnm/BG4JLhLDnPBttOQ7cq11CF7TVEe+ajvpDPY EVNL8XuK84mbYkULTsjUbQiTsl+EQSupwwQfY2CApX+4avQ7o/Ju+qqfd+ydQtkCnu0M5 V8l8/12uwANwuiXZSID56EDQBhXmpXojDqfWqb0dsC/tg1XyDZqO7Xiip9Yc7yTlXsA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792562867; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:Received:From:To:Cc:Subject:Date: Message-ID:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:X-Scanned-By; bh=bPNcZtx1R86/TZx74cw8XerrcoFLwDH2DF9j2lH9uns=; b=d4SFjrTPfKlz/6JnkZ3zxo0qAlHBWR0GSTJOCJXD9OZRgZmBk1MfivpVmOP63S2fPgO1 qJ5whtI0cSVrM/SPYsE1SP7IzCZ/9yMRvnNLGr9Ri2c17TwEl+f37n8RPoQB9LRATuc1s uBu56PEIJXwyEV3TLjazFEbJYKk1nmnqqWMUe2svF6J49rMsoqrm2TQnF/9hFiVFQRnXr ZLCOt5J91XNab/t+F739qKCRDjA1ny0E9htWcH1tMybI3fjfQjp7BQtJ7S5JnvmVGJVWG gy9OVHfid1003qiNaRcpfKaSLBhEn1TxOUNrCnMCpc/XBs1e7z8IVNqc3tZtwFTdp/w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ci0gWiEG; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 626E6606A33F for ; Wed, 21 Oct 2026 06:07:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 626E6606A33F Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ci0gWiEG DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792562866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bPNcZtx1R86/TZx74cw8XerrcoFLwDH2DF9j2lH9uns=; b=ci0gWiEGdyYo/Yt1U7Ljpm+gkjGRqmfZI1QgNCvjikuG3OKxclj885kHhj4rWrXJ676iQg /pJUvCGkmHK2bB4gcSh7toPFxbNuqFEDyVcdwPxa27pAGRqcDEKYnKAWW/TfYoUQTvQZz/ +27jaPOu+vkGSEkLtLF2xhODytpERDg= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-494-BX9fNg00Pkqep9e7R1Z5fg-1; Wed, 21 Oct 2026 06:07:40 +0000 X-MC-Unique: BX9fNg00Pkqep9e7R1Z5fg-1 X-Mimecast-MFC-AGG-ID: BX9fNg00Pkqep9e7R1Z5fg_1792562859 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 348BF180057A; Wed, 21 Oct 2026 06:07:38 +0000 (UTC) Received: from jtornosm-thinkpadp1gen7.rmtes.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E97CE30000E3; Wed, 21 Oct 2026 06:07:35 +0000 (UTC) From: Jose Ignacio Tornos Martinez To: jjohnson@kernel.org Cc: tamizh.raja@oss.qualcomm.com, julius@bairaktaris.de, ath11k@lists.infradead.org, ath12k@lists.infradead.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Jose Ignacio Tornos Martinez Subject: [PATCH v8 1/2] wifi: ath11k: use queue mapping for WCN6750 ring selection Date: Wed, 21 Oct 2026 08:07:23 +0200 Message-ID: <20261021060725.242681-2-jtornosm@redhat.com> In-Reply-To: <20261021060725.242681-1-jtornosm@redhat.com> References: <20261021060725.242681-1-jtornosm@redhat.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 WCN6750 selects the TCL ring using skb_get_hash() to distribute flows across its 3 TX rings, as introduced in commit 7636c9a6e7d7 ("wifi: ath11k: Add multi TX ring support for WCN6750"). The goal was to prevent out-of-order packet delivery that could occur with smp_processor_id()-based selection, where packets of the same flow could end up on different rings depending on CPU scheduling. Switch to skb_get_queue_mapping() instead, which returns the AC (access category) assigned by mac80211 in ieee80211_select_queue(). This provides the same ordering guarantee: packets of the same TID always map to the same AC and therefore always land on the same ring, preventing reordering. Using queue mapping for ring selection also provides QoS-aware distribution, where each traffic class gets a deterministic ring assignment, rather than the random distribution that flow hashing produces. With 3 rings and 4 ACs (VO=0, VI=1, BE=2, BK=3), the mapping becomes: VO and BK share ring 0, VI uses ring 1, and BE uses ring 2. This matches the approach already used by ath12k for WCN7850, which has the same ring count and uses skb_get_queue_mapping() for its ring selector. This change also removes the dependency on skb_get_hash(), which is relevant for a subsequent patch that removes the skb parameter from the get_ring_selector hw_ops callback entirely, enabling TX flow control in wake_tx_queue without requiring a complex peek to inspect frames before dequeue. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Jose Ignacio Tornos Martinez Tested-by: Julius Bairaktaris # IPQ8074 WLAN.HK.2.9.0.1-02146 --- v8: Split ath11k and ath12k into separate series to avoid conflict with Julius's airtime queue limits series (ath11k only) and help to unblock both No code changes from v7 v7: https://lore.kernel.org/all/20260917064825.12747-2-jtornosm@redhat.com/ drivers/net/wireless/ath/ath11k/hw.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/hw.c b/drivers/net/wireless/ath/ath11k/hw.c index 93f9a03c48dc..d679e39dce03 100644 --- a/drivers/net/wireless/ath/ath11k/hw.c +++ b/drivers/net/wireless/ath/ath11k/hw.c @@ -891,13 +891,7 @@ static u32 ath11k_hw_ipq8074_get_tcl_ring_selector(struct sk_buff *skb) static u32 ath11k_hw_wcn6750_get_tcl_ring_selector(struct sk_buff *skb) { - /* Select the TCL ring based on the flow hash of the SKB instead - * of CPU ID. Since applications pumping the traffic can be scheduled - * on multiple CPUs, there is a chance that packets of the same flow - * could end on different TCL rings, this could sometimes results in - * an out of order arrival of the packets at the receiver. - */ - return skb_get_hash(skb); + return skb_get_queue_mapping(skb); } const struct ath11k_hw_ops ipq8074_ops = { -- 2.54.0