From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 529C75477E for ; Sun, 16 Aug 2026 20:15:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786911356; cv=none; b=Hkc8fbBSegb+PHa5SYUP26QhPXITtpudtUf2qvRsNbIXj6qP6WXiolEBSga9ArAAY/54B55inF7z46AN0thoVfi7xyhMAhCvonqeMsMkB583LQJlr3IoUm1rebukr+HBsWVpIL9U0YEUmZx52V18aOxISdQugXWOgpbXa+VagsY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786911356; c=relaxed/simple; bh=YLNFw0AG3etdwrl7ND3i6NgBpPAWyLQnnXdqNZDEzAE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AEEhvw8uxwGGVKRNCKd6VMKZVmWb/srbTmHk4DZ7SyGycd+a73c1KC0n+TQ2XUgxT9MxiYXecklF640AQd0jLBDV2BLVTZz2EHLnb/d+t4QI9xD4rOMUEgx6HINopPQj8i1gPhSY/QwhkEg1JJx+x5M/72WjxRYsDsJaUsDvtLQ= 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=mPl7pPXy; arc=none smtp.client-ip=209.85.128.47 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="mPl7pPXy" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so19965435e9.1 for ; Sun, 16 Aug 2026 13:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786911354; x=1787516154; 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:content-type; bh=hTar65Rimo56P+5q1sfLQwgooJmuM6Drj27jozp+ukw=; b=mPl7pPXyYGRUH7q/JMFRxHfVMUmZFoOLhkukwTPOd4fR7wWR/Dt+9P530BXm3SKfvt 3OkuFr9mZCT2Qu5JRZFgOJ8vQ8sC61hykI678xecxHgB6/d42S6s9p4IT4NrLvq1MzYC pCoj1zB8LE5uQfPEN+qfsJW01zNNI3J8hnhOXN3BMYKfhOp6XLm48dTeM3Fh5xkJJ1is FfrVZ032/X1fMAbD5aM3vfaBmbhiFPTOjec8Fp81iWHuuIVOvobYILisvWxEzTXWn0in Ql0LqFtXML3uQoq3v+12gd6G+fSbUhAMJy7tqhyHNfqUPuZ/A4JDLuUDtH0RQ6zYFtRX rMew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786911354; x=1787516154; h=content-transfer-encoding:mime-version:references:in-reply-to :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=hTar65Rimo56P+5q1sfLQwgooJmuM6Drj27jozp+ukw=; b=IRK7MaAW8wqT7db4OQrp9wPvMKXkDg+GYOhBesWW6Jge8lUIq9SlN6NX1vhTNbgu5H 0rR2MnZjec0s4FBLKaq6akNcKxQVW4A/PIh2tbZmRM/Wc6f76rkq7vfz9ErEGDKhOwbm Xr+IYvQTVfdEQ57in8BmckDWPGqaRqMXSdrZBTpWc5+gZQDByl4Cc65amVgWGaE7fVu9 lsxuWsVJKz5NvdhopbNhvGTXVmEI3ZgLw9IBTQPR+iCXg8QOBMl3Y0OZVjUNQRl4kExM DjvX7ZRj4n38kcwjhkSxCSJ7aq7ghs1bIhND5axkCvW6o9xAddbl0LjAViDpJktmpFqS fpjw== X-Forwarded-Encrypted: i=1; AHgh+RrDnRI8OeUD2VVNxMiD/WMkP4PMz9s9ZRGILWiQPBFYZxMJg8uOR1PewbSkY4zkaNC4Gxkfh6seY4HOKeo=@vger.kernel.org X-Gm-Message-State: AOJu0Yy2Mt4chplWii4a7zGyGSSI0KJVlsPUhgSZxa+CDG5Jn+Z+p0We 1M15iVe5fErvZX25Lk+kE1hU4MWySCvFW+si8oEgDcQBz9PpqMK0gioC X-Gm-Gg: AR+sD13voilVAsmJ/l4QVGIF1RRvqLuDAVuOGdSQ6KLvSnx7z5eq2F4AOrP9zqhFsos CvCNhaHees0NbezNuWqmXHaXa6Ww+nTvr7Bz+VW2pVH4pvlUxLgenwRg00Y0PsNRXO+0VS7cghd k+ig7swjXAEfBXJRRO2nOM0Gg7MWJ26jznwA8u/+k9dInWw2UoxEar1QOH31GW8FQj8m9GRT4z/ Uo4+gOV1YBMuOJ5DpqavZ2vBbGmhCzJoIzbnz1WgB3s1tur7IwEgpqkKYUWCsy/GyPmCkFToxam bxhazfLGIriKIKF0QmtPodMEqzgbY6LoqAU7vGnyi5am/DOkZIjEbYmsdaVkBfSoPKqK/j2A8wr rpWoN7oA2QZrlqR3q1XdftyR+fcis/Xf/uqxQRFZk1mTL3mgrvL34kT9EgEIEsvs6BVPG56ke9w EGX4u+fXl0VektSKIAmJRtmzGg+A2UkzouHdFo8zs82Ap5PaMVWJDVVb50GXAkVfGUnmCqtMDge fw/ X-Received: by 2002:a05:600c:1d1a:b0:495:779a:ed33 with SMTP id 5b1f17b1804b1-49987937fa8mr291351105e9.7.1786911353587; Sun, 16 Aug 2026 13:15:53 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4999610ecf4sm65027975e9.7.2026.08.16.13.15.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 13:15:53 -0700 (PDT) From: Mehmet Fide To: Bitterblue Smith , Ping-Ke Shih Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, mehmet.fide@screeningeagle.com Subject: Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues Date: Sun, 16 Aug 2026 22:15:52 +0200 Message-ID: <20260816201552.291195-1-mehmet.fide@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <9367d61a-bdc7-4d11-a424-428950d74f60@gmail.com> References: <20260813131845.1330003-1-mehmet.fide@gmail.com> <4bb13bf2-8588-4235-a1ec-b82e6668c982@gmail.com> <9367d61a-bdc7-4d11-a424-428950d74f60@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Bitterblue, You don't need real mDNS/SSDP - the driver keys the routing purely on the destination address of the frame, so any multicast/broadcast the AP transmits takes the same path. Real Windows/Apple clients get you there on their own eventually (that is how we first hit it), but here is a deterministic recipe. Setup: RTL8822BU in AP mode (hostapd), DTIM 1, at least one station associated so the BSS is live. Generate the load from the AP host, egressing the wlan interface (use the bridge/interface that carries the BSS, and your subnet's broadcast address): # ~100 broadcast frames/s out of the AP ping -I wlan0 -b -i 0.01 192.168.42.255 Multicast works the same, e.g. "ping -I wlan0 -i 0.01 224.0.0.251", or a UDP loop to the SSDP group 239.255.255.250:1900. The firmware drains the HIGH queue at beacon pace - in my measurements about a dozen frames/s at DTIM 1 - so ~100/s overruns it at once. The shared TX page pool then bleeds down; I polled the free-page count (register 0x240) and watched it fall from ~1800 to low double digits within a minute. Once it bottoms out, new stations can no longer associate (their auth/assoc responses queue behind the backlog) and "error beacon valid" starts logging, because the reserved-page download needs pages from the same exhausted pool. The AP keeps beaconing, so from the air it looks like a silent receive stall; only a reboot recovers. Two knobs confirm it is the queue and nothing else: raise DTIM (e.g. 3) and the HIGH queue drains even slower, so the pool empties faster; drop the ping rate below ~12/s and it never fills. (This is on the v1 thread; the current revision is the v3 I sent as "route bmc frames via the high queue only for DTIM delivery", which keeps the after-DTIM path only for genuinely buffered multicast. The reproduction above applies to both.) Best regards, Mehmet