> On Dec 28, 2018, at 11:07 PM, Jonathan Morton <[email protected]> wrote: > >> On 28 Dec, 2018, at 11:22 pm, Pete Heist <[email protected]> wrote: >> >> This smells of a bug Toke fixed on Sep 12, 2018 in >> 42e87f12ea5c390bf5eeb658c942bc810046160a, but then reverted in the next >> commit because it was fixed upstream. However, if I re-apply that commit, it >> still doesn’t fix it. >> >> Perhaps there are more cases where skb_reset_mac_len(skb) needs to be called >> somewhere for VLAN support? > > I did wonder if there was something about the old kernel messing things up. > > Do you still get acceptable throughput if you disable GRO/GSO at the > interfaces?
Turning off GRO does avoid the problem, but unlimited throughput through the one-armed router gets slashed: GRO on: 920mbit up / 935mbit down GRO off: 510mbit / 534mbit down Incidentally, for those using the v1 PCEngines APU, turning off rx-vlan-offload provides much better throughput for traffic routed from VLANs (presumably a quirk of the Realtek r8169 driver): ethtool -K eth0 rxvlan on: 494mbit ethtool -K eth0 rxvlan off: 936mbit It would be great if there’s a way to work around this in cake on older kernels, but I’m not holding my breath. It’s also very possible that the current fix in newer kernels takes care of this case, even if the original workaround in cake does not. This was the kernel change: https://patchwork.ozlabs.org/patch/968734/ <https://patchwork.ozlabs.org/patch/968734/> So far, I’ll just use prio for this at lower throughputs and htb or drr if the CPU is taxed. This works well enough on 3.16, all things considered…
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
