oliviertilmans
commented
5 years ago Hi Dave,
Somehow I received 0 notifications from GH about this? -- and was about to archive the repo when I saw the (!) icon next to its name.
Thanks for the suggestions. I'll try to find spare cycles to tweak these behaviors before the next netdev submission.
Due to GRO/TSO which imparts a dynamic range of 64b-64k bytes on "packets", for a new linux kernel submittal I'd recommend using a byte limit only and not supporting a packet limit at all.
I agree with the byte vs packets point Do you know if cgroups can set memory limits on the kernel part of a net-ns? I'd be wary otherwise of "no limit at all" in a containerized env.
Similarly, given the fine granularity of signaling I'd recommend you also include gso/gro splitting. There are examples of both techniques in the fq_codel_fast, tbf, and cake qdiscs.
This wasn't a concern for us so far, given that the qdisc is merely intended for testing purposes (wifi/lte/docsis/dsl bottlenecks each use other implementations). I understand however that you may run into real situations where the bottleneck is actually this qdisc (i.e., east-west container traffic that would apply a low MTU for some reasons), hence where this would matter. The fact that GRO also 'does the right' thing (as opposed to LRO) when forwarding is I guess another argument to support this anyway.
dtaht
Due to GRO/TSO which imparts a dynamic range of 64b-64k bytes on "packets", for a new linux kernel submittal I'd recommend using a byte limit only and not supporting a packet limit at all.
Similarly, given the fine granularity of signaling I'd recommend you also include gso/gro splitting. There are examples of both techniques in the fq_codel_fast, tbf, and cake qdiscs.