Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On Thu, Feb 27, 2014 at 6:08 PM, clanlab.proj clanlab.p...@gmail.com wrote: On Thu, Feb 27, 2014 at 5:25 PM, clanlab.proj clanlab.p...@gmail.com wrote: Hi all, After I've replaced the WEIGHT/budget from 16 - 32, I've got better performance from previous NAPI version, but still cannot beat the work queue version. Dear all, Update a benchmark of single tcp RX session comparison. I've tested NAPI implementation with (budget) WEIGHT = 8, 16, 32. and work queue implementation. The picture below is the analysis result by wireshark to present a visualization. http://i.imgur.com/wluSt4f.png Compared with the iperf log and wireshark statistic result, you can see the work queue method gets the best result among the other tests includes the maximum throughput and minimum throughput. If you compared the result of budget change, you can see when WEIGHT = 8, you will get the most smooth throughput but it cannot reach the maximum result of all NAPI method. I have not test the others scenarios, for example, to compare the difference of multiple sessions or bi-directional traffics. But I think I won't do these test. According to the testing result right now, I'll suggest work queue method instead of NAPI implementation. Best regards, Weinn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On Wed, Feb 26, 2014 at 5:13 PM, Weinn clanlab.p...@gmail.com wrote: On Mon, Feb 24, 2014 at 10:57 PM, Manu Gautam mgau...@codeaurora.org wrote: On 2/22/2014 11:11 AM, Clanlab (Taiwan) Linux Project wrote: In order to reduce the interrupt times in the embedded system, a receiving workqueue is introduced. This modification also enhanced the overall throughput as the benefits of reducing interrupt occurrence. Hi all, I've found that the NAPI version of my implementation was slower then the previous work queue implementation. I think I can post it later and let's see where the parameters codes/ could be adjustment. Currently the weight/budget of rx_napi is 16 (GETHER_NAPI_WEIGHT == 16) netif_napi_add(net, dev-rx_napi, gether_poll, GETHER_NAPI_WEIGHT); Should I send a new patch which with new description about NAPI version? Or should I just send the patch v3 and use the same patch subject? Here is the benchmark (USB High speed) on RX channel. (PC-Device) With work queue is implemented. [ 3] 2.0- 3.0 sec 9.75 MBytes 81.8 Mbits/sec [ 3] 3.0- 4.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 4.0- 5.0 sec 10.2 MBytes 86.0 Mbits/sec [ 3] 5.0- 6.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 6.0- 7.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 7.0- 8.0 sec 9.88 MBytes 82.8 Mbits/sec [ 3] 8.0- 9.0 sec 10.5 MBytes 88.1 Mbits/sec [ 3] 9.0-10.0 sec 10.5 MBytes 88.1 Mbits/sec With NAPI is implemented. [ 3] 23.0-24.0 sec 9.25 MBytes 77.6 Mbits/sec [ 3] 24.0-25.0 sec 9.50 MBytes 79.7 Mbits/sec [ 3] 25.0-26.0 sec 9.75 MBytes 81.8 Mbits/sec [ 3] 26.0-27.0 sec 9.25 MBytes 77.6 Mbits/sec [ 3] 27.0-28.0 sec 9.12 MBytes 76.5 Mbits/sec [ 3] 28.0-29.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 29.0-30.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 30.0-31.0 sec 9.62 MBytes 80.7 Mbits/sec [ 3] 31.0-32.0 sec 10.0 MBytes 83.9 Mbits/sec Best regards, Weinn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On Thu, Feb 27, 2014 at 5:16 PM, Weinn clanlab.p...@gmail.com wrote: I've found that the NAPI version of my implementation was slower then the previous work queue implementation. I think I can post it later and let's see where the parameters codes/ could be adjustment. Currently the weight/budget of rx_napi is 16 (GETHER_NAPI_WEIGHT == 16) netif_napi_add(net, dev-rx_napi, gether_poll, GETHER_NAPI_WEIGHT); Should I send a new patch which with new description about NAPI version? Or should I just send the patch v3 and use the same patch subject? Here is the benchmark (USB High speed) on RX channel. (PC-Device) Hi all, After I've replaced the WEIGHT/budget from 16 - 32, I've got better performance from previous NAPI version, but still cannot beat the work queue version. Here is the result.. With NAPI: WEIGHT/budget == 32 [ 3] 10.0-11.0 sec 9.88 MBytes 82.8 Mbits/sec [ 3] 11.0-12.0 sec 9.38 MBytes 78.6 Mbits/sec [ 3] 12.0-13.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 13.0-14.0 sec 10.2 MBytes 86.0 Mbits/sec [ 3] 14.0-15.0 sec 10.0 MBytes 83.9 Mbits/sec [ 3] 15.0-16.0 sec 10.5 MBytes 88.1 Mbits/sec [ 3] 16.0-17.0 sec 9.38 MBytes 78.6 Mbits/sec [ 3] 17.0-18.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 18.0-19.0 sec 10.4 MBytes 87.0 Mbits/sec With work queue is implemented. [ 3] 2.0- 3.0 sec 9.75 MBytes 81.8 Mbits/sec [ 3] 3.0- 4.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 4.0- 5.0 sec 10.2 MBytes 86.0 Mbits/sec [ 3] 5.0- 6.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 6.0- 7.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 7.0- 8.0 sec 9.88 MBytes 82.8 Mbits/sec [ 3] 8.0- 9.0 sec 10.5 MBytes 88.1 Mbits/sec [ 3] 9.0-10.0 sec 10.5 MBytes 88.1 Mbits/sec With NAPI is WEIGHT/budget == 16 [ 3] 23.0-24.0 sec 9.25 MBytes 77.6 Mbits/sec [ 3] 24.0-25.0 sec 9.50 MBytes 79.7 Mbits/sec [ 3] 25.0-26.0 sec 9.75 MBytes 81.8 Mbits/sec [ 3] 26.0-27.0 sec 9.25 MBytes 77.6 Mbits/sec [ 3] 27.0-28.0 sec 9.12 MBytes 76.5 Mbits/sec [ 3] 28.0-29.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 29.0-30.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 30.0-31.0 sec 9.62 MBytes 80.7 Mbits/sec [ 3] 31.0-32.0 sec 10.0 MBytes 83.9 Mbits/sec -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On Thu, Feb 27, 2014 at 5:25 PM, clanlab.proj clanlab.p...@gmail.com wrote: Hi all, After I've replaced the WEIGHT/budget from 16 - 32, I've got better performance from previous NAPI version, but still cannot beat the work queue version. Hi all, Just to remind you, I've send an another patch which replaced rx_work with rx_napi. The subject of that patch is [PATCH] u_ether: move hardware transmit to RX NAPI So we can discuss which implementation is better to be adopted and better to the system. Thanks for your review and suggestion. :) Here is the result.. With NAPI: WEIGHT/budget == 32 [ 3] 10.0-11.0 sec 9.88 MBytes 82.8 Mbits/sec [ 3] 11.0-12.0 sec 9.38 MBytes 78.6 Mbits/sec [ 3] 12.0-13.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 13.0-14.0 sec 10.2 MBytes 86.0 Mbits/sec [ 3] 14.0-15.0 sec 10.0 MBytes 83.9 Mbits/sec [ 3] 15.0-16.0 sec 10.5 MBytes 88.1 Mbits/sec [ 3] 16.0-17.0 sec 9.38 MBytes 78.6 Mbits/sec [ 3] 17.0-18.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 18.0-19.0 sec 10.4 MBytes 87.0 Mbits/sec With work queue is implemented. [ 3] 2.0- 3.0 sec 9.75 MBytes 81.8 Mbits/sec [ 3] 3.0- 4.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 4.0- 5.0 sec 10.2 MBytes 86.0 Mbits/sec [ 3] 5.0- 6.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 6.0- 7.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 7.0- 8.0 sec 9.88 MBytes 82.8 Mbits/sec [ 3] 8.0- 9.0 sec 10.5 MBytes 88.1 Mbits/sec [ 3] 9.0-10.0 sec 10.5 MBytes 88.1 Mbits/sec With NAPI is WEIGHT/budget == 16 [ 3] 23.0-24.0 sec 9.25 MBytes 77.6 Mbits/sec [ 3] 24.0-25.0 sec 9.50 MBytes 79.7 Mbits/sec [ 3] 25.0-26.0 sec 9.75 MBytes 81.8 Mbits/sec [ 3] 26.0-27.0 sec 9.25 MBytes 77.6 Mbits/sec [ 3] 27.0-28.0 sec 9.12 MBytes 76.5 Mbits/sec [ 3] 28.0-29.0 sec 10.4 MBytes 87.0 Mbits/sec [ 3] 29.0-30.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 30.0-31.0 sec 9.62 MBytes 80.7 Mbits/sec [ 3] 31.0-32.0 sec 10.0 MBytes 83.9 Mbits/sec Best regards, Weinn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On Mon, Feb 24, 2014 at 10:57 PM, Manu Gautam mgau...@codeaurora.org wrote: On 2/22/2014 11:11 AM, Clanlab (Taiwan) Linux Project wrote: In order to reduce the interrupt times in the embedded system, a receiving workqueue is introduced. This modification also enhanced the overall throughput as the benefits of reducing interrupt occurrence. This patch looks to be derived from: https://android.googlesource.com/kernel/msm/+/08eb78ebbee92e4f133fc75237cf6af6356c38b6 Hi Manu, After checking your comment, I've found the patch we were referenced from github could probably be derived from msm.git (according to the time stamp of patch/commit) Since I've already fix the patch according to the suggestion on the mailing list and for kernel 3.13 and later. Do I need to add any git comment to list the earlier idea as a reference before the 3rd version of the patch is sent? How does the reference and the format should be looked like? Dose any one could give me any suggestion? Thanks! Best regards, Weinn. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On 2/22/2014 11:11 AM, Clanlab (Taiwan) Linux Project wrote: In order to reduce the interrupt times in the embedded system, a receiving workqueue is introduced. This modification also enhanced the overall throughput as the benefits of reducing interrupt occurrence. This patch looks to be derived from: https://android.googlesource.com/kernel/msm/+/08eb78ebbee92e4f133fc75237cf6af6356c38b6 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] u_ether: move hardware transmit to RX workqueue
On Sat, Feb 22, 2014 at 01:41:52PM +0800, Clanlab (Taiwan) Linux Project wrote: In order to reduce the interrupt times in the embedded system, a receiving workqueue is introduced. This modification also enhanced the overall throughput as the benefits of reducing interrupt occurrence. Signed-off-by: Clanlab (Taiwan) Linux Project clanlab.p...@gmail.com You need a person to have a From and a signed-off-by:, not a project, sorry, that doesn't work at all and means the patch must be rejected. Please use a real name for kernel development, it is required by what you are agreeing to when you use the line Signed-off-by:, didn't you read it? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
