From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 254BA480DD2 for ; Thu, 13 Aug 2026 15:07:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786633627; cv=none; b=OER51xOLhb3kyDB2Xs3lE/CUJZy2U6qxKp42B5wAjnpGqHvQ1Bq8HQvvmmb6bAlqkbicZfzIAqbIFdTcWrYkzRyfklWAl2p9eWI2FWMici1anm8ZvZhC1XKKaIBQbmLyWdHrkP8vSJGw8v5ILVP4c0E49HD7z3lpjmgOXkGlMsY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786633627; c=relaxed/simple; bh=o55Z0TctzZ1TV0FZdKaCHaRccaP3Zl3sp7oRzJhRtiw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=k2H70q7HM4TkZBzTkiU7JhBT/R0X2499jHrE9EMcH31S0ubxh4ozzCVZrl8wmJg6B9oy/mF7mEy/g4JlVGXNf3+i5V9x2PhGiamB7JCR/KUSBUyyznQPOUWATTy/UbJgcH5iwcTovN9TmToiTgmsiNnM9YBVDKzE/NokYCweoi8= 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=VQaMGKRi; arc=none smtp.client-ip=209.85.221.50 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="VQaMGKRi" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-471eeac43bfso730089f8f.3 for ; Thu, 13 Aug 2026 08:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786633624; x=1787238424; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Cl8SsiBieJKZTfoRpN8BaDOycOWZISr8O2wW18dZcc0=; b=VQaMGKRiy2MJFzy2xFskqJOfMPLJ8LBMJ7ZgIgnb4jO79ad0qwg+wWrGBldoDc47lU nvuJdZ/64f9+uIh89V12rlb6qk4TdL0pPGZsSKsscu38uHv6YEQ08U4L/nIENQJwolmO WNCVpA7DQOsZl3hbTilITdGEjmHmVQrfdDMV501EZAHHLXNY2wNe/6FdbEmEATuVZsNQ NqDAZ6J9KsM6sV4F4hkCJdrLdoFHQR/wtFd5KF6d0akYlbnToyA0TlfnAqRE3tXlesfD tvsFrFv0Rgz+fETZh11qdItKPkm4sCPMHluEe8va6KvXl/j9vGG4duzUQy8tw4ayUVTR 32hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786633624; x=1787238424; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Cl8SsiBieJKZTfoRpN8BaDOycOWZISr8O2wW18dZcc0=; b=s1JRHdSvulaRAW9/VsDvKDjLrmkoBVshHDTyaIBmDriVgfSm/U68CA7mfBZxt56fd7 RRqOcA+sfECHCZWi3IpvTu/KEDSr+D4vtQytY43zyxcQZCs+n9/3uRST3ABgJtN/CCv9 yu+Lrr6YquD8wlrOaGRDEWWh8T7Bb8i1MFcZD8gJYAbQ0KH3NDn03E3H6jv9fTtGNSb5 KNZOxkqdDTPtbqA8KVLrlCGZ7bdEwu1+tVfAZIwHA+DfzmnhXVTMHAuYDIBEFgSUpODs BVmBKcRU2oz+Epr/up+/gXshsXGUJNVdIDY7VDd87o5Y6HqrQf+fwzzf5kovXy+vhVdv oxJw== X-Forwarded-Encrypted: i=1; AHgh+RodWUUEjNuB4SoP+5rzbH1OO7d/P9CssqLlGtLftCiAL8GubTPb4J9y0JehDlEibD9nlt0EPjJSXZvb3kc=@vger.kernel.org X-Gm-Message-State: AOJu0Yxix/wKASq9sSei1lMyZJqJcgUj5f9CnujNPtUFQNeeF513SNJ8 E+ZrOl1bjP2IwcQRJfEFFSw6q2E8DkNrgYb/AHXSDbcX8xWwWVbS4f5s X-Gm-Gg: AR+sD11vELGSAjUM05FXf52Zk2Xf02ZyxV9ZA+MAMk4NUg2pvY1DqFFfBDEasSvMqZp /N0hetLUGQA8qU92XDpYXTV/JgdEHdwUKS6AE/v5wj84IacbIfAOkdPvDFIXXXHNouTlaN2ixGd mFvNyTnH9K3dGYBRiKriZigXFLnlZpo2vqNXtfijXorHxu1IMBPrKkbqAdBc5itPyGNAyIB1Dlr T8sz4rociu0D2LOE33wdo7VKF5Y7hiflC+Dm9fA74EtQbMaXtIQIUCM31Km1may1ZTKhJBifBp6 FUr3ttqGlYqHGwKexe/JOP2aKsmuMIeTWAgJ+j2l1vRk9OphlIFTrFr25BXzXQmUbVR6x53cnNJ V7BfTeev02C0DsObDQZmRT8yUnoc0pkL/nUMOmjEkfQauBBftol4OvPi4VUbowsO+y2ROFZurkG l8zDtBSHVGqgR4VIsTOqGc8CXTWzahdND3oapswS3aOaOe9V3ENiJ/sRSEdMeBDVEl95NJ6WM= X-Received: by 2002:a05:600c:6287:b0:495:4689:1e98 with SMTP id 5b1f17b1804b1-499821845d2mr84008575e9.10.1786633623879; Thu, 13 Aug 2026 08:07:03 -0700 (PDT) Received: from [192.168.1.50] ([79.119.240.229]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499820f5d26sm48570965e9.1.2026.08.13.08.07.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2026 08:07:03 -0700 (PDT) Message-ID: <4bb13bf2-8588-4235-a1ec-b82e6668c982@gmail.com> Date: Thu, 13 Aug 2026 18:07:01 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues To: Mehmet Fide , Ping-Ke Shih Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Mehmet Fide References: <20260813131845.1330003-1-mehmet.fide@gmail.com> Content-Language: en-US From: Bitterblue Smith In-Reply-To: <20260813131845.1330003-1-mehmet.fide@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13/08/2026 16:18, Mehmet Fide wrote: > 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 I wonder if you can reproduce this problem with kernel 6.5? It looks like commit 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM behavior") from 6.5 was supposed to fix the exact same problem. This is also the commit which introduced the code you are now removing. > --- > 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