From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 F20A947DD40 for ; Thu, 13 Aug 2026 13:18:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786627130; cv=none; b=RGeH9TgRLffq54Cy4QGga5J+91Bx9nX9B66Jr25uKzPug95F8Kd90744Nxaja+H9rI2m6IpPWKGKJvnP4RGLHj4LtS0/R7z88RSB7FbFdTXpk2mMzSrSUWjsZHH/I83C4mDXmp4kASjTx9+TLFz4gYbTHsb6mnRrQpiocvvCBes= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786627130; c=relaxed/simple; bh=IgzU5nG+19vPkXH8D+e1/TsOIkhQUEQwkbr3QsZ1qOI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=oPh35g3BtG6WIGhQK+ewPqBPcanHGn9Atjvl4VPxEemZkE6QDE1XDk10Ll7nXg7BGpSOgBBW93ezPaKMEfVv8c+NLa8aFxkyEvDGdx5ULCDv8pnaXb7mzdcRp9OHk8i5BUEp6Lgn5XDHDEfIyL62cpG84rTeBQtH06XUkwnP6iI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lEtKvY1c; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lEtKvY1c" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-499840a2575so3442785e9.3 for ; Thu, 13 Aug 2026 06:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786627127; x=1787231927; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=NHIC2WNshsHmkNk84taa0XjH0hARwcrGEdD93mjza+c=; b=lEtKvY1cRkuYRybexRKqjv3UFzAy00VgGdTiDGPKNKaHmgPM4uNl7hu4wWPEFq1dG9 NXNH30Op9KmgWSy+pOKDH9SUdDmTINQerfPtC6MpS5AnuEnq9ou1YdOOHkMNp6RfipHq Fc2truNh/zeOdlEV+YNJfAZHiORCQxoOUysM6qvPuQNkyKiLG65f6V/EzFCuab6nXHt+ uFoYlsYZmXiMbudgi5vu6KvWEKw4Zs2fh/aDpn9fZsoUQMNqGV7iZnkChSMgQtkR2McU HsL+l7fLR452NGCfmf2FOlvH96s+lw7pKgZY8iYRYJmiEeJDKw8/n1wfSUMoUgqhvPg+ 9NFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786627127; x=1787231927; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NHIC2WNshsHmkNk84taa0XjH0hARwcrGEdD93mjza+c=; b=coRNBktcajcHSPDGFal4gEAesC7it6Q62mJSHwvI6bqzrxOsoL1EA3Po3g2PqLJ0Pj 5SVH7s7r6FZvqc9Ky5jWU3npSn+xsseu58+3CFflrqo+OueXYDPFuv9feJS4frGZF7hz UlUm9ELTj5moR12L8mLR0xTMz0o8sFvUDqjnUKBi5YnO8CaPfPrRxrww6rbwD9Ki4xsi TzNZ5LLA+Ib9WqEykUZor64fZlzyz3JGjJ/wm3P+H8i7Kffy9JDLTlvNx098HmFvr+Yn c9qF+16TOkM77Jn79uADRgVjJbRTubQmYgu8qoPSM0A2irsoeiFLYPBXvrVcHyfkktun 8/9Q== X-Forwarded-Encrypted: i=1; AHgh+RooFb0cxfqaTFApg3jzjkTpKBWztV4cs4PE6fRDwwLGp7gKb7fQZmSJxnSPK9IGZ9huZl8PT7RUwoAiJrQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwwAgvztZoFo/a5DbniPs6WHhfKu4SsgGRmQfCGN8+xQO5Tpd4G r1i6wPLS45KVFG2Ax6xZQG6JwXeV1qJCVSV7AisSsfeuWX13kPji4kAP X-Gm-Gg: AR+sD11+RQdHiUDtzjLyjqQfECJZtpXLbE7K6QEmOyZH2+8VG563KE++Xg7AmvLs97Q 2Fd9xz0yl5fPctfK/6PZayp0mTempRPn3lLLYgTuaEa+lckkjzNrsgW8wjNj/042fbnJYH2OHu0 HDLvCZiS8RYfpM2IIEFMOOZvQYFSeJeEX5rs/sRPuLLhesfd4CnCnUtJZJdPz627zSL7HJujY2F 8jTAM5wSwqxyOoWjZ6stkUsWv1w4eWmoctcp4UHkQrca+MUL9JfnAQyVoMGs8HNofbcGoRZBbUG s7J5e55ybN2GX/kXLbuckKDFnC2IXEJPiQQOUlYwZoJh4Cd/oD0U6lH9zUMo7aDrw6bfCrw1s/D a2hn9APnHS6dw1aryoCrqBI+oGV6T0AYXGdvdHorYQaKRbGQGBsMg0Ymlf0Zquh389c0/dQXT2r gVrfXjea2WsxJaXXVQYWMGZTYFXf3HAu2CYmLCqGdqiDI9eqdl6wJNIMA8lh5YXAazGw== X-Received: by 2002:a05:600c:8b54:b0:493:a613:56b2 with SMTP id 5b1f17b1804b1-4998216b3bdmr84898375e9.8.1786627126889; Thu, 13 Aug 2026 06:18:46 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4998216d082sm63740045e9.13.2026.08.13.06.18.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 06:18:46 -0700 (PDT) From: Mehmet Fide To: Ping-Ke Shih Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Bitterblue Smith , Mehmet Fide Subject: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues Date: Thu, 13 Aug 2026 15:18:45 +0200 Message-ID: <20260813131845.1330003-1-mehmet.fide@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mehmet Fide In AP mode every broadcast and multicast data frame is routed to TX_DESC_QSEL_HIGH, the after-DTIM queue. The firmware drains that queue at beacon pace, roughly a dozen frames per second, while a single associated client's mDNS/SSDP chatter alone exceeds that. The excess accumulates inside the chip until the shared TX page pool is exhausted; measured on RTL8822BU, 14 of 1803 pages were left. From that point every host-sourced frame queues behind the backlog: authentication responses reach the air seconds after the client has given up, so no station can associate anymore, and the beacon reserved-page download fails the BCN_VALID poll ("error beacon valid") because it needs pages from the same exhausted pool. The AP keeps beaconing throughout, so from the outside this looks like a silent receive stall, and only a reboot recovers. On USB the HIGH, MGMT, BEACON and H2C queues additionally share one bulk-out endpoint, so the jam also head-of-line blocks firmware commands. Route broadcast/multicast data through the regular AC queues instead. They then leave at line rate and the page pool never fills. The trade-off is that stations in power save may miss multicast that the after-DTIM queue would have buffered for them; at the chatter rates that trigger the jam those frames were being dropped anyway. On a bench AP (RTL8822BU, USB2, 20 MHz, WPA2, hostapd, a Windows client driven through disconnect/reconnect cycles): reconnects fail 0/5 before this change and pass 5/5 with it, with the page pool staying healthy and no beacon errors logged. Signed-off-by: Mehmet Fide --- drivers/net/wireless/realtek/rtw88/usb.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c index 64e1c3420..f528fe0f2 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -565,9 +565,6 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct sk_buff *skb) if (unlikely(ieee80211_is_mgmt(fc) || ieee80211_is_ctl(fc))) qsel = TX_DESC_QSEL_MGMT; - else if (is_broadcast_ether_addr(hdr->addr1) || - is_multicast_ether_addr(hdr->addr1)) - qsel = TX_DESC_QSEL_HIGH; else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK) qsel = skb->priority; else -- 2.54.0