> On Aug 22, 2018, at 11:37 AM, Toke Høiland-Jørgensen wrote: > > Pete Heist writes: > >>> On Aug 22, 2018, at 8:17 AM, Jonathan Morton wrote: >>> >>> One difference between fq_codel and Cake is that the former - which >>> has no shaper - will "bypass" packets when it's empty and there's no >>> back-pressure filling it. In that case no packet classification >>> occurs and filters will not be called. Or at least, that's how it >>> used to be set up; I haven't looked at it recently. Cake does not >>> rely on the same set of assumptions, so will always call the filter. >> >> Aha, that sounds likely, I’ll try with htb and a rate limit. Testing >> with fq_codel was challenging as I had to “do stuff” until my printk’s >> were eventually called, but it’s easier now that I can use cake. I >> suppose in my case fq_codel’s behavior would be ok in production, >> because if there’s no queue then there’s no need to classify. Maybe in >> some other cases (like gathering stats), it could be problematic. > > fq_codel turns off the bypass capability if you attach a tc filter to > it, though, so if the issue you're seeing is that you filter function is > not being called, that sounds... strange... > > How do you check if the function is being called? With printk and "sudo tc exec bpf dbg” to tail the output. For example, in act_main of this file I just added one more line to print “act_main” if TCU_DEBUG is defined: https://github.com/heistp/tc-users/blob/master/tc-users-bpf.c And here’s an example of verifier weirdness (not that you need to look into this)… If IPV6_SUPPORT_V2 is defined but TCU_DEBUG is not, the verifier error is: "math between pkt pointer and 4294901760 is not allowed" If IPV6_SUPPORT_V2 is defined but TCU_DEBUG *is* (which just defines the prink func and adds two printk lines, and otherwise works without IPV6_SUPPORT_V2 defined), the verifier error is: "R3 bitwise operator &= on pointer prohibited"