Memory limits are better than packet limits

[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.

[oliviertilmans]

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]

Olivier Tilmans <[email protected]> writes: Well, I try to help.