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=1792562866; b=LrkO1GU34nHm8Gd6iSzO0ojdfS6UqCwuJDA351cXCP4ydwG3gIUcZTa3d0Xdnks6HVnW 6JgzKwOIRRnl+ehccaZel1Sbj8TwAQX4vuU/9+zB0eT2mL568ireV+WI4wm4kELKZNT7w 7YbA5rplhLuIiy+TMWF1oOyqqttD3QluEVa3Uuk+HtelQZ2zWKCIvuKZAsp/m2OR6Vjpr tkxAKxl0Wu90axB8q/PWiy+tOoc02MyZDz4X3nC4017cgHkwYuVh/pOtR/JR0fVfKM4MY 0mnm+ReUOY0CboeOidlFgnIpjiFyjit8gQ7kzgLvMJPUsfsBNm2BxhZ+pv7TlpoNv+Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792562866; 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=eU7/sOsUV60+ESgQviVizruePNYP1LFDkEq8jOHvU2j+eVyLm+Q5KWyAXLYcQJ/FlTQQ mWUC/KKNxwH6q8D4BzwH3M0ehnbUzQDdeK7zIwFX+fACAV7kIyweYD7c30V6ym2xgdeVk AN5KDu6hnZwmIzGMBlNh1iy6PDYL1J89kxeqyQablCuTajfhQ76fNvSSQPUaQK56JziR7 p1p3aqgkmxaUHL0Vl6+cdHcepVUe5fTP7itfpr/4LAwnITJDOqI5d3TifxyXxibvoVpR0 qhlZAa7ruAdDglGwOFhQ62L2xykJRfbexTxg6wObawjOKtUqtBjzHlWzBpEiV/1FN8w== 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=Qe9aE4C4; 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 77333606A33D for ; Wed, 21 Oct 2026 06:07:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 77333606A33D 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=Qe9aE4C4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792562864; 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=Qe9aE4C4tYQa0N6dTKmO6xq/gY1rmn4qrtIFakdjyTMfMELeIihbZwFEwWdUc3rdIGzgFS uE150UV/10mGDhUuCquCrMeZzZ/ZzKEM6HWZ7PHjL+ju4W3KQizutH1tQvrpBQhm7Wyw0X mLPuNx6Uv+0TjNlaRSJMyB7ZsA9l0YQ= 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-wireless@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