Hi, This might be a dumb question, but I recently touched this and felt like I'm missing something basic -
NAPI is being scheduled from soft-interrupt contex, and it has a ~strict quota for handling Rx packets [even though we're allowing practically unlimited handling of Tx completions]. Given these facts, what's the benefit of having arbitrary large Rx buffer rings? Assuming quota is 64, I would have expected that having more than twice or thrice as many buffers could not help in real traffic scenarios - in any given time-unit [the time between 2 NAPI runs which should be relatively constant] CPU can't handle more than the quota; If HW is generating more packets on a regular basis the buffers are bound to get exhausted, no matter how many there are. While there isn't any obvious downside to allowing drivers to increase ring sizes to be larger [other than memory footprint], I feel like I'm missing the scenarios where having Ks of buffers can actually help. And for the unlikely case that I'm not missing anything, why aren't we supplying some `default' max and min amounts in a common header? Thanks, Yuval -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
