From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 CAF3429C327 for ; Sun, 16 Aug 2026 20:15:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786911347; cv=none; b=LixfZftjfL2+04VLKYwGtKmSHQcaFCHnzv6LTSTFGzGbWmv0ruwntEE+tKRnDCUySnbjIF5NOEb45RUaA4Lkum+o1rGWots2QK5ClQ/+rUsfJupwZ16O0WFOGv4TEhmmGAt0GWTCgqDfs16T2keMt1Z9dg7lbpJ2VbVkNNmT2WA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786911347; c=relaxed/simple; bh=YLNFw0AG3etdwrl7ND3i6NgBpPAWyLQnnXdqNZDEzAE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V7plD58OPpVULFSaspeFyjQla0L7f1OMXffGzKjYAA6gS/ojQAP6dBuut6k8ajMoUOz3zvPuuKwS5reYsIB9Xocn3lNu+J5ZFyi7jK9qSorGy28xF9fsm663et+ZpCV0tuRnoL4g765GwSgZX5p6L//waz81oYZg2OuGfsA9Umg= 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=QXkDo/Td; arc=none smtp.client-ip=209.85.128.54 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="QXkDo/Td" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-496bb7cdf51so34497575e9.2 for ; Sun, 16 Aug 2026 13:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786911344; x=1787516144; 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=QXkDo/TdepBojPSPAxhQPSyDDXuveKd5HMEocxdmaNAovCIrEXImChNobnvVivY/XH gZTw82Nr/MNqP/ocjpvw3TAbje4/jUUVN9EaMaaxIvCXuWvLi0EKk8jGStW6fYT6w3Ca Io8y4y+CrVcBfAoktXsJ1IKytbtaazY8BVdFg4ypaRw0wqb8kHb+XhKTX6JG7J2REbUB tcShrwXV3wcn7PI0K8C1CbsxDeaXQTx5MskXUiVOR9Fq1drD1zmPce9ov/i8SaIWqCUM ziswpIl0rrJ93ysTb3caeBCdyDzuVxomJ/EEhb9cMloQ6oHtAXBErCZ0N3JEppoKoPkc DNuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786911344; x=1787516144; 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=hajLiw1G7+minWpxp+hcXodhUlzi2oZjc2fNo4FfAYuRu5Lje3ohJ+gXEfuHvgNZPE Fv/yf4BFr3wpX56e8VBPnSDlQvb9gOgljwXUsgKHsQdo9B1PD7z63XXoJR6WWqK0dqCW Zq51+z7GcGOsJVAvI+kkDgne9A/Paos6vzgVaYMZllCgZKz/+I+Nx1zUl2sCR+3gdyKp RZIreo9k01lOft24KkoGQ+o6UOeOq1BCiMK3Tio4Lv5BlDBYV5GoOEoQAlE/bCLVcscJ CAR2z/CLlFfIgc9HQ8PcYzUrZ3xL9jCnLoTFPskRV9DHCvTw6sN5KmJ11EgAh30fk0Y7 Fd+g== X-Forwarded-Encrypted: i=1; AHgh+RoTabd3gNRHHmMgJ9HVe4Tla6r0SUQI4WtRIsWx5qmySiFZD4SFf3D0Hq0FYz3znGbGNVd0ttdPmaRa75A=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0KPvdcr18dYtzouHUBORoe1ZrmViKjv9vcjCiLw0b82H/ABR3 J3F1zC+jsR1xoezvcTm0vBvWBwMLtY9zde1THp8vRULBJwrJUkwwRptJ X-Gm-Gg: AR+sD10CnX94YVhJBrGdK4I5tpVORoZYAxWUawU86oRTm5r7EhqD4AWr3XAuiAbAite gcdjm0gj6HVlAJ6whH4LUKo6vcK831gFwzMH44CWz/BWIf4E61t1L8E2UEQsIXQoCykYK+g1qgj ZDi7Ul25s+pBw7mE39PamXfHyKPiq5dVwTMYkLu0d0Wha/jjf1thcOCuHf81/fgE0NGlAVQ+F70 lY62S2p/zNuZGnAYM61BMqh5bdJNohtDpvZJf01rqopP36X6PB0+PqTdsh6NMe3XxhXiatjpmuw mmw8ye9MmZA5mPni/eACNN/jlCeizS9ZPzZNrp2HQ5sLKF3ELYMtMn45ecBWRAH1//Ij5bNdZid +2yRK6EpiRqTi5MiM/5EpJdS4++KaWsrUd1qMuUEj6V1sQaIoosad2p0TCsiveMMSdSp7Kxjohi VcN9SLuqPBNkuTUE5W4n7RRLrOXM2+MKvif1j8ASkvV2MhVL2+PPY4pnhzbg1osCZMpA== X-Received: by 2002:a05:600c:600a:b0:495:52a5:8829 with SMTP id 5b1f17b1804b1-49987981e14mr223870225e9.11.1786911343891; Sun, 16 Aug 2026 13:15:43 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49996127629sm67000195e9.14.2026.08.16.13.15.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 13:15:43 -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:42 +0200 Message-ID: <20260816201542.291030-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