From nobody Sat Feb 7 18:21:29 2026 Received: from rtits2.realtek.com.tw (rtits2.realtek.com [211.75.126.72]) (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 67EED37E307; Thu, 15 Jan 2026 11:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=211.75.126.72 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768477371; cv=none; b=VJl6cZCYbJebjs34bib8SeyVp/5o7jtrnItIzisk3Ca4c1cqomjFVXTW72jSvmokmbmfqoK96cS5bFu3VXCGYGDthd5LFYevXa+jgosWLhxi1JwUeo1nsm434o0O7VwH2IJLesnm+A2GG1LxactNLuG/TVCgxCcO+R07/7M8eLE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768477371; c=relaxed/simple; bh=63dl3TNPU5nwdThJj/EBkKixN0LIH7NW8BAMlypNW+k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=YM2zmB4SDRyEiv7iritD3+6o8xLWf1WNQY61L7P4St80+U+wWCw/8DycZkdi34teaKhakPy9BSg0hqunhEjUPUASmJbz3IS1KKsw3MsAiehswjBPKuvGrNR5Ka1PQARTm2Pb4cOnfweudDV0vYv6vLqfUmCYnLvQKDXsYOMftf0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=realtek.com; spf=pass smtp.mailfrom=realtek.com; dkim=pass (2048-bit key) header.d=realtek.com header.i=@realtek.com header.b=QD02b6F3; arc=none smtp.client-ip=211.75.126.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=realtek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=realtek.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=realtek.com header.i=@realtek.com header.b="QD02b6F3" X-SpamFilter-By: ArmorX SpamTrap 5.80 with qID 60FBgLHS12959073, This message is accepted by code: ctloc85258 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realtek.com; s=dkim; t=1768477341; bh=63dl3TNPU5nwdThJj/EBkKixN0LIH7NW8BAMlypNW+k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=QD02b6F3HVNB9WkRoVclfsLcaQtCsABc/bdOc+pqMvvChpW3W9t5MUiQQiY8LQUVA EkNgb0/5TVG5WLFCdHo93emd5/KuQPM7L1FK1GfS+ivHuBkM6A+mMWiPiqvjZZI/36 xC24eDsJM98ryWbUWbD/aPlg2N1vXWfVUf4ksgrIoCDjgAQrUAL7XY+HiTZ4+PczQz Om06AcZDh6jjFjjeA9f/B6BanQG97Uqwjsw7AYQIunHOOlYPfGZfZOaCSfbJwPjBtQ mcTV7obWrCB+xFC4kTbgMGvIE4nrB6pdKvUA0aAmgo26kw4I9xavBYuTX3YZbRWEib An3EvQ9oZBIRg== Received: from mail.realtek.com (rtkexhmbs02.realtek.com.tw[172.21.6.41]) by rtits2.realtek.com.tw (8.15.2/3.21/5.94) with ESMTPS id 60FBgLHS12959073 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Jan 2026 19:42:21 +0800 Received: from RTKEXHMBS03.realtek.com.tw (10.21.1.53) by RTKEXHMBS02.realtek.com.tw (172.21.6.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.10; Thu, 15 Jan 2026 19:42:20 +0800 Received: from RTKEXHMBS03.realtek.com.tw ([fe80::8bac:ef80:dea8:91d5]) by RTKEXHMBS03.realtek.com.tw ([fe80::8bac:ef80:dea8:91d5%9]) with mapi id 15.02.1748.010; Thu, 15 Jan 2026 19:42:20 +0800 From: Hayes Wang To: lu lu CC: "andrew+netdev@lunn.ch" , "davem@davemloft.net" , nic_swsd , "tiwai@suse.de" , "linux-usb@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] net: usb: r8152: fix transmit queue timeout Thread-Topic: [PATCH] net: usb: r8152: fix transmit queue timeout Thread-Index: AQHchQGLBs/iMEigv0CwXIii7EgMTLVRErBAgADcLoCAASPVoA== Date: Thu, 15 Jan 2026 11:42:20 +0000 Message-ID: <1b498052994c4ed48de45b5af9a490b6@realtek.com> References: <20260114025622.24348-1-insyelu@gmail.com> <3501a6e902654554b61ab5cd89dcb0dd@realtek.com> In-Reply-To: Accept-Language: zh-TW, en-US Content-Language: zh-TW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 lu lu > Sent: Thursday, January 15, 2026 9:37 AM [...] > To reduce the performance impact on the tx_tl tasklet=E2=80=99s transmit = path, > netif_trans_update() has been moved from the main transmit path into > write_bulk_callback (the USB transfer completion callback). > The main considerations are as follows: > 1. Reduce frequent tasklet overhead > netif_trans_update() is invoked frequently under high-throughput > conditions. Calling it directly in the main transmit path continuously > introduces a small but noticeable CPU overhead, degrading the > scheduling efficiency of the tx_tl tasklet. > 2. Move non-critical operations out of the critical path > By deferring netif_trans_update() to the USB callback thread=E2=80=94and > ensuring it executes after tasklet_schedule(&tp->tx_tl)=E2=80=94the times= tamp > update is removed from the critical transmit scheduling path, further > reducing the burden on tx_tl. Excuse me, I do not fully understand the reasoning above. It seems that this change merely shifts the time (or effort) from tx_tl to = the TX completion callback. While the intention is to make tx_tl run faster, this also delays the compl= etion of the callback, which in turn may delay both the next callback execution and the next sched= uling of tx_tl. From this perspective, it is unclear what is actually being saved. Have you observed a measurable difference based on testing? If you want to reduce the frequency of calling netif_trans_update(), you could try something like the following. This way, netif_trans_update() would not be executed on every transmission. --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -2432,9 +2432,12 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struc= t tx_agg *agg) netif_tx_lock(tp->netdev); - if (netif_queue_stopped(tp->netdev) && - skb_queue_len(&tp->tx_queue) < tp->tx_qlen) + if (netif_queue_stopped(tp->netdev)) { + if (skb_queue_len(&tp->tx_queue) < tp->tx_qlen) netif_wake_queue(tp->netdev); + else + netif_trans_update(tp->netdev); + } netif_tx_unlock(tp->netdev); Best Regards, Hayes