Re: [Codel] [Cerowrt-devel] FQ_Codel lwn draft article review

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

On Mon, 2012-12-03 at 12:31 +0100, Dave Taht wrote:
> ADSL benefits from closely tieing buffering to being nearly
> zero and to signalling the actual packet delivery from the hardware.

Er, does it? 

ADSL is basically just ATM with a strange PHY. You have a bunch of
options for how you use this ATM link. Mostly it's RFC2364 PPP-over-ATM
or it's PPPoE on top of RFC2684 Ethernet-over-ATM.

In about the 3.4 kernel I fixed PPPoATM to limit its queue depth to 2
packets, so the PPP netdev queue/qdisc is *fairly* much in control. And
thus I think fq_codel should work, even if we don't have BQL on PPP?

In net-next a couple of days ago, I fixed the BR2684 driver to limit
*its* queue depth to 2 packets too, so there there's "only" the
txqueuelen on the 'nas0' virtual Ether-on-ATM device, which defaults to
100 packets, below the PPP netdev. If you cut that down to single
figures, perhaps fq_codel stands a chance on PPPoEoA too?

I'd actually like to track those packets all the way down, and make BQL
work on PPP devices generically — by installing a skb destructor so that
we get notified when the packet *actually* leaves the box, however many
layers of tunnelling it goes through. What we have so far is helpful,
but surely BQL will still make things better?

There's also straight IP on that virtual Ethernet interface too, which
is rarer. And then the nas0 interface would be the one with your default
route, and you'd be using fq_codel directly on that. So it should be OK.
I have posted an RFC patch to the netdev list which adds BQL to BR2684
virtual Ethernet devices, but it's "interesting" because the ATM driver
normally prepends a header before handing it to the ATM device... which
means that the packet we account as *completed* is larger than the
packet we account as *sending*... and the BQL code panics the box when
that happens. I have a workaround, which seems mostly OK.

However, none of this helps much in the case where the PPPoE part and
the Ethernet-over-ATM part are done on separate boxes; a separate ADSL
"modem" and then your own box doing PPPoE to it. In that case, you just
hope that the "modem" does some kind of flow control... is that even
possible for PPPoE or would it have to use pause frames at the Ethernet
level?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]