Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
* [Cake] Peeling question
@ 2015-08-26 14:52 Sebastian Moeller
  2015-08-27  5:25 ` Jonathan Morton
  0 siblings, 1 reply; 2+ messages in thread
From: Sebastian Moeller @ 2015-08-26 14:52 UTC (permalink / raw)
  To: cake

Hi Jonathan, hi Dave,

I have just been discussing GRO/LRO/TSO/GSO type meta packets (for lack of a better name) and their influence on temporal traffic shaping granularity (and fine timescale fairness). I know that cake solves this problem the most elegant way by peeling/decomposing the meta packets into nice pMTU sized chunks, but until cake hits openwrt or mainline we need to get away with bigger hammers, namely disabling meta-packets entirely. I believe that they need to be disabled on all interfaces to be effective as say a meta-packets assembled on say a WLAN-interface with GRO enabled will e passed onto WAN even if the WAN-interface has GSO disabled, is that correct? 
	So the 1. question boils down to on which interfaces the offloads need to be disabled, on all interfaces or only on “real” interfaces? Or more specifically with cerowrt nomenclature: will ge00 be sufficient or do I also disable it in pppoe-ge00 and ifb4pppoe-ge00? By default GSO and GRO are enabled on those interfaces?
	My second question is how do you guys actually test this? How can I create a situation with a very high likelihood of meta-packets appearing? (If I know this I can go figure question 1 myself…)

On a related note it would be sweet if cake could report the maximal sizes of packets it gets fed in and the maximum sizes it ejects; so for non-peeled meta-packets I expect to see say in: 64K out: 64K and for peeled rather in: 64K out: 1514 or so.

Best Regards
	Sebastian
	


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Cake] Peeling question
  2015-08-26 14:52 [Cake] Peeling question Sebastian Moeller
@ 2015-08-27  5:25 ` Jonathan Morton
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Morton @ 2015-08-27  5:25 UTC (permalink / raw)
  To: Sebastian Moeller; +Cc: cake

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

I'm not *absolutely* sure that the following is correct - I'm extrapolating
a little.

Except to say that GSO and GRO have zero impact on packet format or size on
the wire (unlike jumbo frames).  It's entirely reasonable for packets sent
with GSO to be received without GRO and vice versa.  Of that I am certain.

Interfaces that don't support GSO, or where it is turned off, will
automatically receive only individual packets.  You can examine this
capability using ethtool, which works fine on wifi interfaces as well as
genuine Ethernet.

I haven't tried ethtool on PPP-anything, but I wouldn't expect to see
support for offloads there.  If for some reason it is there, by all means
turn it off.

Probably the easiest way to observe GSO in action it to run Codel or
fq_codel on the relevant interfaces, without shaping, and put a heavy but
simple TCP load, such as nttcp, through it.  Watch the maxpacket stat in tc
-s qdisc.  Some hardware is more aggressive than others.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 1135 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-08-27  5:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-26 14:52 [Cake] Peeling question Sebastian Moeller
2015-08-27  5:25 ` Jonathan Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox