[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0835B3720019904CB8F7AA43166CEEB2ECE0DF@RTITMBSV03.realtek.com.tw>
Date: Mon, 10 Nov 2014 05:23:14 +0000
From: Hayes Wang <hayeswang@...ltek.com>
To: Francois Romieu <romieu@...zoreil.com>
CC: David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
nic_swsd <nic_swsd@...ltek.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: RE: [PATCH net-next v2 2/3] r8152: cleartheflagofSCHEDULE_TASKLETintasklet
Francois Romieu [mailto:romieu@...zoreil.com]
> Sent: Sunday, November 09, 2014 6:12 AM
[...]
> The performance explanation leaves me a bit unconvinced. Without any
> figure one could simply go for the always locked clear_bit because of:
> 1. the "I'm racy" message that the open-coded test + set sends
> 2. the extra work needed to avoid 1 (comment, explain, ...).
Thanks. I would modify this patch with clear_bit only.
> The extra time could thus be used to see what happens when napi is
> shoehorned in this tasklet machinery. I'd naively expect it to be
> relevant for efficiency.
I thought about NAPI, but I gave up. The reasons are
1. I don't sure if it would run when autosuspending.
2. There is no hw interrupt for USB device. And I have
no idea about how to check if the USB transfer is
completed by polling.
3. I have to control the rx packets numbers in poll().
However, I couldn't control the packets number for
each bulk-in transfer. I have to do extra works to
deal with the rx flow.
4. I don't find much different between tasklet and NAPI.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists