RE: [PATCH net-next v2 1/2] r8152: add RTL8152_EARLY_AGG_TIMEOUT_SUPER
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) < 0x ? \ > + CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER * 125 : 0x))) 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, 0xu) David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next v2 1/2] r8152: add RTL8152_EARLY_AGG_TIMEOUT_SUPER
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) 0x ? \ + CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER * 125 : 0x))) 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, 0xu) David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
