From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 DEDF248C8C1 for ; Thu, 13 Aug 2026 18:50:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786647029; cv=none; b=rV+JS4sg5KVshAzeMH0KQUGf0l7wO75361+cBeVUTHac0nX74b1blmKuEDUFQw2bDT9X3PRDPj7f0Ui17dU9n8rG4Ll1lskMKp2r1j4MWXeBP6XFbSWmTqXHVLjqYBbP22GFh94cjnozptF+b1itr7h5IiuU8mTs3uAq+piaK1Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786647029; c=relaxed/simple; bh=AkBKR03uCxQT0b9C6hxQnaA2qPJn7M9baAsRN+oR/ps=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Jr0x5uNDqXhKDgYnXFGtzGRsQ7wSPcagBXqhXAzb1g+gklSViAj8CVvXHd56JASQaR1KE3HQWAKhWvYDVW+xmj14Arh8X+M5bj2gy8SgKbZbgWoRCm4bhDqUhGPLmIVodO3MK1ZQVkvDvT/0NpGBMg/XIUTB8CEzlH2U7pmV82o= 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=PgdTXFxR; arc=none smtp.client-ip=209.85.128.48 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="PgdTXFxR" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4954aff6088so2235715e9.3 for ; Thu, 13 Aug 2026 11:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786647023; x=1787251823; 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=4CmqxsU45YaJX65GG/NrnTX1eKbG2HH3nIDBeKynSsg=; b=PgdTXFxR7JpV8T0EZL3wHKu+TJn7GXYrtCxC8nONFDnKuKGRy7qnHTLzEVFTFNVKt/ lb4soRV5zsHugWWppl1MUzGm+sN6gufvvHfdGwEuN8bmtoOPfK0brrjNAHxqaShwilGn 84QtXSeTjWmK1aZnoHl6lNsKi+KqgqTsFVba+3DWos6I837EYFuv4vmk3JTwztdTyQ8E lkMJI06Jf6F6hQS1HL/dNZmhMfGe4WqwIPLNoWejrU2jUqqVtAMtZy7WrzPPgC2sU1+A y5/HQH/gwaOgcD1+bONDMSDRNcOmxFpefkGNi4EA5CUe/LL2xzQmiAFshm2UTy6cZ6dt /O4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786647023; x=1787251823; 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=4CmqxsU45YaJX65GG/NrnTX1eKbG2HH3nIDBeKynSsg=; b=hX+HDurJlt1+TuHFahayMkzD2NVlRQtBeqbF0+EKNSxt5nZCRqjYnQAPmueg+3jse1 UlWbR8E4/Qj5yUhocmf2Th6mLX2srOIA7Uluc0Djmm5leNvgE+BJKKybGKzvAV42nJqY W9O82Yi2iJuhhbVNPd5TYPgoML3ah1f1mMELx0T/OeWNzKeE8kmqKdykNfMOPUtgi5X9 UzGp4XVjSt/6JwlDioS3HKfaS3GNtBIT3rjRProqLC/2N7x0Zszb8jZXGu1uIYMX+IkM s6UkPTXt/0sZadxFS4ZDUJ/+tSBe9qRztxNkD1Oqo9HgvKNWZo8HjEoKzeZ/n+oQtE1N YdMA== X-Forwarded-Encrypted: i=1; AHgh+RpUsBQchTmkCP9bkhXVecmKaqL2RxxSIcL/+K6hym7mncqcu11rlFHXfT1AT3jgFfUN65N3xMWflSt9uOU=@vger.kernel.org X-Gm-Message-State: AOJu0YygEO/Xeusa3AI+CJP3cw79pjgGenEmhMHs/I8p+20Y80zAjx4f m8bHtdLS6TcIsLHcTmdCnOKGSNr70c/sqIqGVNrTLMZxd0/JfrbMLDww X-Gm-Gg: AR+sD11/5t6JGJ0E3qiB9K3XQvreUrSWQ+jc8C4iPJ5bD2mYanYIQqz1t0ngO+DYKeD tHxgnJ5bMqOw8EZLb8D1kzGjnFf0CCs87TOM9p/yE4vUJySFD+L0sdt8aXNe1wftgMBgAmBi0Ug YhNJgiRY2fDMzCbkMa4Gg7ZO8X0RGHu/SOpUDFrM2gncOgCqqojKzqznk+TTIFd1/fLTx0lmzDA KVSdhjJUd+4hy6V16wIJaatBHJouKqCcGFNyQq1udm1u4vaValTAX4DFCKt2PEQEBibGS0B2d+R 8gTI82JxDPoLCsxN+WGgzCJnQORcVct9BEWCYMIWm0VJY2lp6Rcn3i6aO1/u3lxHyPXcxVAcFtU autrDdEAqn4JQ9zd2RMBN6/uDuHfcIfsv4CaOUrIoxXVLTvkPhn2tmUEyjzvve0htoslGp9Xzew waVCkv4aABcAxFexPcRhfgXaQpUEF6t7Zs6fOT6SowFEWSvcjSbVjCDpk5RafwdZCBkA== X-Received: by 2002:a05:600c:2055:b0:499:819e:db2c with SMTP id 5b1f17b1804b1-499879ace10mr4265345e9.16.1786647023237; Thu, 13 Aug 2026 11:50:23 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4998216d082sm83608805e9.13.2026.08.13.11.50.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 11:50:22 -0700 (PDT) From: Mehmet Fide To: Bitterblue Smith Cc: Ping-Ke Shih , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Mehmet Fide Subject: Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues Date: Thu, 13 Aug 2026 20:50:21 +0200 Message-ID: <20260813185021.2290877-1-mehmet.fide@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <12eaffd0-9d0f-44bd-8163-d05b6a3df611@gmail.com> References: <12eaffd0-9d0f-44bd-8163-d05b6a3df611@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 From: Mehmet Fide Hello Bitterblue, > Could you check what the official driver is doing in the same situation? > > https://github.com/morrownr/88x2bu-20210702 Good timing, we had already done exactly that comparison before your mail arrived. That driver was our working reference on the same bench throughout the investigation (5/5 reconnect cycles where in-tree fails 0/5), and we went through its AP transmit path to understand why it is immune. It handles this quite differently, in five ways: 1. bmc frames are buffered only while a station is actually dozing (sta_dz_bitmap check in core/rtw_xmit.c, rtw_xmit_ap_enqueue). With no sleeper present they leave immediately through the normal AC path, which is what my patch restores for rtw88. 2. The buffering happens in software (the bmc sta's sleep_q), not in the hardware high queue. The hardware HIQ receives at most one DTIM burst at a time (chk_bmc_sleepq_hdl), so it can never accumulate into the page pool the way rtw88's standing high queue does. 3. Even then, a filter decides what may ride the HIQ at all. The default (rtw_hiq_filter=1, "allow special") lets only ARP, EAPOL and DHCP through; mDNS/SSDP chatter never enters the high queue. The rest of the buffered frames go out through the normal queues when the burst is released. 4. The driver owns the TIM bit itself: it sets it when it starts buffering, pushes the updated beacon, and clears it only after both the software queue and the hardware HIQ are empty, polled through HW_VAR_CHK_HI_QUEUE_EMPTY. It does not depend on a beacon download whose pages come from the same pool the backlog is exhausting. 5. MORE_DATA is set on every burst frame except the last one, which carries 0 and terminates the burst. rtw88 sets it on every high queue frame including the last. That may be part of why I measured the burst fetch not happening here even with BIT_TCR_UPDATE_HGQMD set: the hardware never sees the end marker the vendor code provides. So the field-proven driver never routes bulk multicast through the high queue either, sleeper or not; the high queue is a small, filtered, explicitly terminated DTIM burst buffer for it, not a transport path. Given that, I still think routing bmc through the AC queues is the right minimal fix for rtw88 USB. If you want to keep buffered delivery for dozing stations I am happy to work on the fuller shape, meaning PS tracking plus a software staging queue released at DTIM, but that is a much bigger change and the current behavior is a hard AP breakage. Thanks, Mehmet