On Wed, Mar 16, 2011 at 12:01:41AM +0200, Jonathan Morton wrote: > > On 15 Mar, 2011, at 10:51 pm, John W. Linville wrote: > > >>> If you don't throttle _both_ > >>> the _enqueue_ and the _dequeue_, then you could be keeping a nice, > >>> near-empty tx queue on the host and still have a long, bloated queue > >>> building at the device. > >> > >> Don't devices at least let you query how full their queue is? > > > > I suppose it depends on what you mean? Presumably drivers know that, > > or at least can figure it out. The accuracy of that might depend on > > the exact mechanism, how often the tx rings are replinished, etc. > > > > However, I'm not aware of any API that would let something in the > > stack (e.g. a qdisc) query the device driver for the current device > > queue depth. At least, I don't think Linux has one -- do other > > kernels/stacks provide that? > > I get the impression that eBDP is supposed to work relatively > close to the device driver, rather than in the core network stack. > As such it's not a qdisc, but instead manages a parameter used by > a well-behaved device driver. (The number of well-behaved device > drivers appears to be small at present.)
If you count mac80211 as part of the "driver", what is between the qdisc and the "driver"? I wouldn't consider the bottom of the qdisc as the core of the stack. I would really like to see eBDP (or ALT or A* or something similar) implemented in a single place if possible, rather than reimplemented (perhaps poorly) in a series of drivers. I know Felix and others think that 802.11n aggregation makes that impossible, but I'm inclined to think that is still at least partly from a bias towards throughput at the expense of latency -- I could be wrong! :-) Someone suggested that perhaps eBDP/ALT/A*/whatever could be implemented as a library for drivers to call -- that still requires individual driver hacking, but maybe it is reasonable? I'd have to see the code. > So there's a queue in the qdisc, and there's a queue in the hardware, > and eBDP tries to make the latter smaller when possible, allowing the > former (which is potentially much more intelligent) to do more work. So that is a possible implementation -- limit the tx queue length in the driver, similar to manually doing 'ethtool -G'. But on the other hand, you can achieve a similar effect by throttling the input to the driver/hardware tx queue no matter how many hardware tx slots are physically allowed. <snip> > Knowing the occupancy of the hardware buffer is useful if the > size of the buffer cannot be changed, because it is then possible > to simply decline to fill the buffer more than a certain amount. > If you can also assume that packets are sent in order of submission, > or by some other easy rule, then you can also infer the time that > the oldest packet has spent there, and use it to tune the future > occupancy limit even if you can't cancel the old packet. Yes, I think we agree. > Cancelling old packets is potentially desirable because it allows > TCPs and applications to retransmit (which they will do anyway) > without fear of exacerbating a wireless congestion collapse. I do > appreciate that not all hardware will support this, however, and it > should be totally unnecessary for wired links. As other said later in the queue, I think trying to reach down into the driver/hardware to cancel an already posted packet would be difficult, slow, etc. John -- John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
