On Fri, 2012-12-21 at 13:45 -0500, Jim Gettys wrote: > > I've been working with blogic (John Crispin) on debloating the Lantiq > driver, which we are trying to test; since it is entirely open source. In > the Lantiq DSL driver case, the hardware sprouted exactly the same sort of > transmit/receive rings found in ethernet drivers, with the corresponding > bufferbloat due to device drivers being totally stupid. Unfortunately, BQL > is ethernet only, and right now doesn't work properly at low bandwidths.
Hmmm. With the code that's currently in OpenWRT, we shouldn't *let* the ATM driver have a huge queue of packets unless it's doing something egregiously stupid like calling the vcc->pop() function on the skb before it's actually sent it. PPPoATM for a long time has limited the queue at the hardware driver to 2 packets, instead of a full sock_wmem's worth of buffers like it used to in the past. Since a couple of weeks ago the BR2684 driver (Ether-over-ATM, as used with PPPoE on top) also does the same thing. So the ATM driver would have to go out of its way to screw you over¹. John? Btw, I'm looking at ways to *make* BQL on the PPP netdev work properly, tracking packets all the way to the wire even when it's PPPoA, PPPoE(oA), L2TP or whatever. -- dwmw2 ¹ Unless you're using IP over ATM directly. I haven't looked at that one.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
