2013/8/8 Florian Fainelli <flor...@openwrt.org>:
> - 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
I tried hacking bgmac.
1) TX
I removed all error handling from bgmac_dma_tx_add and
bgmac_dma_tx_free. Just for sure (not trusting compiler) I replaced
variables with some inlining, added "(un)likely" where possible, for
example:
if (unlikely(++ring->end >= BGMAC_TX_RING_SLOTS))
2) RX
As you suggested I replaced
napi_schedule(&bgmac->napi);
with
if (likely(napi_schedule_prep(&bgmac->napi)))
__napi_schedule(&bgmac->napi);
Well, it didn't help :| I still get
1) 87Mb/s for LAN -> router
2) 155 to 165Mb/s for router -> LAN
When running "iperf -s" I noticed some new "__lock_text_end":
7498 total 0.0029
1778 __lock_text_end 0.4759
1778 *unknown*
495 __copy_user_common 0.7112
492 __do_softirq 1.1284
267 csum_partial 0.1870
173 tcp_transmit_skb 0.0685
169 dev_hard_start_xmit 0.1033
155 r4k_dma_cache_wback_inv 0.7176
122 process_backlog 0.2652
109 tcp_sendmsg 0.0274
106 ___pskb_trim 0.1767
105 ip_finish_output 0.0969
105 __bzero 0.2949
not sure if that matters...
--
Rafał
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
