From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-90.mta1.migadu.com [95.215.58.90]) (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 D4182437454 for ; Wed, 19 Aug 2026 09:18:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.90 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787131102; cv=none; b=knDbuFhbyBUwG8xNGmuteA1m5Q3jC/3VHESJSmYfdOEvv5mnQgUeufYl5X1qe9JT09svWQSe+G3QaftPZZSr61mi1t7P4O+0stj4Ca6jrklACX2g3QNG3RlHUM9jHUpbCqhjhggQMLLFAlAo7Re5jmOFQgytpNm8FaX9PMhWAo8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787131102; c=relaxed/simple; bh=TX6877FJkQoV7h2ddq34564u66tziExxw7N+KyZCcsU=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=pswzYegRVlfExICNIIAMyV0E6rOSAVKSTSreLtTAjGOKnjX9Nslf8oAAFmbaohtw61cugqw/pQWTMPOTE8HmF8IwcJp+3sSHUVrBaGonsIoPxAWyE5rnfPwFRxbTbpo+krvaMrquLhOnVld3VxVhGVtI3/cAcd/hhaRkqBUEDAs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Mwgdxjgj; arc=none smtp.client-ip=95.215.58.90 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Mwgdxjgj" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=TX6877FJkQoV7h2ddq34564u66tziExxw7N+KyZCcsU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787131083; v=1; x=1787735883; b=Mwgdxjgj2D1rp5Z1jbhKo6jvUk9nWqv/hx8GdgGCRfnMech2gl+aK/6O9VsYMTIfnKjy70QF S9HAITsu2ogacPsgHyK1uOqVDeu9nosPV1W60luJESMIjJD2WK5O/n32I2xSq1VAgqDIklRThFj XFPCbK9OVjjroJSxu899jpvA= X-Envelope-To: linux-kernel@vger.kernel.org Received: from ehlo.thunderbird.net (2a06:63c5:9b00:3900:e1b3:d7a6:6110:4f65) by smtp.migadu.com with ESMTPS id 03b6973c4a51d997; Wed, 19 Aug 2026 09:18:02 +0000 X-Migadu-Flow: FLOW_OUT Date: Wed, 19 Aug 2026 11:17:57 +0200 From: Luka Gejak To: Ping-Ke Shih , "linux-wireless@vger.kernel.org" CC: "linux-kernel@vger.kernel.org" , Michael Straube , Bitterblue Smith , Peter Robinson , Hans de Goede , luka.gejak@linux.dev Subject: =?US-ASCII?Q?RE=3A_=5BPATCH_v5_6/6=5D_wifi=3A_rtw88=3A_sdio=3A_add_T?= =?US-ASCII?Q?X_back-pressure_and_retry_on_page_starvation?= User-Agent: Thunderbird for Android In-Reply-To: <459e54292cf245e2ae6fd1a46afb6ec7@realtek.com> References: <20260814105327.6687-1-luka.gejak@linux.dev> <20260814105327.6687-7-luka.gejak@linux.dev> <257b9af907e84e439ae6a9fd55bf3f09@realtek.com> <20260819071932.19596-1-luka.gejak@linux.dev> <459e54292cf245e2ae6fd1a46afb6ec7@realtek.com> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ping-Ke, > I didn't get this point=2E I'll review carefully on this part in v6=2E Easier to see side by side, so here it is in full=2E Upstream ignores the return value of rtw_sdio_process_tx_queue(): rtw_sdio_process_tx_queue(rtwdev, queue); if (skb_queue_empty(&rtwsdio->tx_queue[queue])) break; and that function puts the frame back when the write fails: ret =3D rtw_sdio_write_port(rtwdev, skb, queue); if (ret) { skb_queue_head(&rtwsdio->tx_queue[queue], skb); return; } So after a failure the queue is not empty, the loop does not break, and the transfer is retried, up to the limit of 1000=2E rtw_sdio_write_port() returning -EBUSY from rtw_sdio_check_free_txpg() is the ordinary case here, and upstream just spins until pages free up=2E v4 and v5 put this in the same loop: ret =3D rtw_sdio_process_tx_queue(rtwdev, queue); if (ret > 0) break; if (ret < 0) { if (rtl8723bs && (ret =3D=3D -EBUSY || ret =3D=3D -ENOMEM)= ) { rtw_sdio_reschedule_tx_work(=2E=2E=2E); return; } break; } The inner condition is chip gated=2E The break is not=2E On every other SD= IO part rtl8723bs is false, so any error, including that ordinary -EBUSY, now leaves the loop and abandons the queue for the rest of the pass instead of retrying it=2E That is the change I did not intend, and it was not in v3=2E v6 has no break there at all: ret =3D rtw_sdio_process_tx_queue(rtwdev, queue); if (ret > 0) break; if (rtw_sdio_8723bs_reschedule_tx(rtwdev, work_data, queue, ret)) return; if (skb_queue_empty(&rtwsdio->tx_queue[queue])) break; rtw_sdio_8723bs_reschedule_tx() returns false on its first line for anything that is not an RTL8723BS, so the other parts get process, requeue on failure, queue not empty, retry, which is upstream's flow=2E > If you have another SDIO chip, such as RTL8723CS, please verify your > patches on another real hardware, because it is not possible to catch > all flaws by reviewer (like me)=2E Using real hardware with a simple > throughput test is more important=2E Agreed, and you are right to ask=2E I do not have another SDIO part=2E The only SDIO hardware I have is the RTL8723BS, so I cannot give you a measured result on another chip, and I would rather say so than imply coverage I do not have=2E This is exactly the bug you would expect that gap to produce=2E So that a reviewer knows where to look, after v6 the other SDIO parts see three changes, all structural: - rtw_sdio_tx_kick_off() uses mod_delayed_work(=2E=2E=2E, 0) instead of queue_work()=2E Only the RTL8723BS ever arms a delay, so for the others the work is always queued immediately, as before=2E - INIT_WORK() becomes INIT_DELAYED_WORK() on the same handler=2E - rtw_sdio_deinit_tx() gains cancel_delayed_work_sync() before destroy_workqueue(), needed once the item is a delayed work, and a no-op where no timer is ever armed=2E Everything else is behind rtw_is_8723bs()=2E If anyone on the list has an RTL8723CS, RTL8822BS or RTL8821CS to hand, the full tree is at: https://github=2Ecom/MocLG/rtw/tree/8723bs-v6 and a plain iperf3 run either way is all it needs=2E I will take any result on another part over my own reading of the diff=2E Best regards, Luka Gejak