2013/8/8 Florian Fainelli <[email protected]>: >> I did some tests using "iperf" for various transfers. >> 1) Between two machines in the same VLAN: 710Mb/s > > So that case is just switching; nothing goes to the CPU port
That's right, I just wanted to confirm switch configuration is OK and my machines are alright too. CPU of SoC wasn't involved in this case. >> 2) Between separated VLANs (WAN to LAN): 90Mb/s > > Are the WAN and LAN interface two different physical interfaces at the SoC > level? If so, both the switch is involved to untag the frames and then do some > routing in software This is a standard router with 5 RJ-45 ports. I'm pretty sure all of them and handled in the same way (connected to the same switch). I could try assigning different VLAN to each port and test something like LAN#1 to LAN#2 just for sure. >> 3) Machine to router (iperf -s on OpenWrt): 180Mb/s >> >> That 90Mb/s speed it pretty slow, there are Internet providers with a >> faster connections in their offer. So I really would like to improve >> that. I know Broadcom managed to get much faster transfers with their >> firmware, so it's definitely do-able. >> >> Do you have any suggestions on achieving that? I was doing above test >> with some BCM4706 router, in "top" I noticed "sirq" eating 99% of the >> CPU (similar report: https://dev.openwrt.org/ticket/7356). > > ksoftirqd is the kernel thread responsible for servicing software IRQs which > is the context in which Ethernet frames are processe for the RX path, what > this means here is: > > - you are CPU bound; the hardware might be moving packet faster but software > cannot keep up > - the NAPI implementation (if existing in the driver) might need some > tweaking, in particular I see no likely(__napi_schedule_prep) for instance Thanks for this tip, I didn't know about it (__napi_schedule_prep + likely). I also think we could make some optimizations in the software, that's why I asked about profiling. >> Should I play with some profiler? >> /proc/profile (and readprofile user space tool) doesn't support >> profiling modules :( >> I didn't play much time with oprofile yet, unfortunately it's new >> profiling method doesn't support MIPS >> (http://oprofile.sourceforge.net/doc/perf_events.html) - so I have to >> play with legacy profiling method. > > perf works just fine on MIPS, I am using it on a regular basis, oprofile does > as > well, although I have not used it that much. I didn't know about that tool, thanks for pointing. Reference: https://perf.wiki.kernel.org/ -- Rafał _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
