Hi Daniel On Mon, Dec 03, 2018 at 03:44:46PM -0600, Daniel Santos wrote: > I almost managed to get that patch in a build to send to somebody who > can reproduce the error in abundance, but they have 15 different people > hammer the router to do it and we ended up sending them a few other > experimental builds instead. > > I'm still learning this driver, but I don't see where it creates a > struct net_device -- was that something that came out after the driver > was originally written? (And maybe gets implicitly created somewhere > else?) It is done in ieee80211_if_add(), one netdev per vif. > iiuc, the best way to do this is by setting tx_queue_len while > the interface is down (via "ip link") and then allocating the queue when > it's brought up. We have diffrent queues at various levels in the network stack. The queues size I plan to increase are referenced as HW queues > Unless you know of a problem with this approach, I'm planning on making > a patch just for that. It will then be easier to tune for an end user's > particular application. I don't think it's correct approch. Maybe module parameter will be better just for testing. But since this is for routers/APs just making build with diffrent tx queues size seems to be better approach. > For instance, if there is a small number of > uses who just use a very large amount of bandwidth then buffer bloat > could become a problem if it's too high. But for a larger number of > users I don't think the buffer bloat probably will matter as much as > lost performance from dropping frames and needing to re-request many > lost packets at the TCP layer. This would also result in more uplink > bandwidth being consumed. Well, I guess that correct, but I still wish to see if increase queues size do not cause big negative effect. Thanks Stanislaw
