From: Hayes Wang > For slow CPU, the frequent bulk transfer would cause poor throughput. > One solution is to increase the timeout of the aggregation. It let > the hw could complete the bulk transfer later and fill more packets > into the buffer. Besides, it could reduce the frequency of the bulk > transfer efficiently and improve the performance. > > However, the optimization value of the timeout depends on the > capability of the hardware, especially the CPU. For example, according > to the experiment, the timeout 164 us is better than the default > value for the chromebook with the ARM CPU. The best value probably depends on the workload as well as the cpu speed. I wonder if a sane algorithm for dynamically setting this value exists. It really needs a CBU (crystal ball unit), but working ones are difficult to come by. Passing the buck to the 'user' is rather a cop-out (but we all do it). > Now add RTL8152_EARLY_AGG_TIMEOUT_SUPER to let someone could choose > desired timeout value if he wants to get the best performance. ... > /* USB_RX_EARLY_AGG */ > -#define EARLY_AGG_SUPPER 0x0e832981 > +#define EARLY_AGG_SUPER ((((rx_buf_sz - 1522) / 4) << 16) | \ > + (u32)(CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER <= 0 ? 0x2981 : \ > + ((CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER * 125) < 0xffff ? \ > + CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER * 125 : 0xffff))) The 0x2981 would be better written as (85 * 125). But maybe replace with something like: min((CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER <= 0 ? 85 : CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER) * 125u, 0xffffu) David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
