Re: [Cake] issue with Cake and bpf filter

[Pete Heist <pete@heistp.net>]

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


> On Aug 21, 2018, at 11:17 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Well that’s good timing for me as I’m wrapping up a small utility/eBPF
>> to classify an arbitrary username to either MAC or IP. Here’s the work
>> in progress, which is not done yet as flow fairness is still under
>> construction, and I haven’t gotten my IPv6 support to pass the rather
>> stubborn eBPF verifier: https://github.com/heistp/tc-users
>> <https://github.com/heistp/tc-users <https://github.com/heistp/tc-users>>
> 
> Did you see my classifier? Does subnet-to-flow mapping. https://github.com/tohojo/tc-classifier <https://github.com/tohojo/tc-classifier>

Yes I did, that helped a lot with the eBPF code! I’ll consult it for LPM trie usage, which will have to be ifdef’d out though for pre-4.11 kernels.

tc-users is similar really but I desired a few things (for FreeNet):
- MAC and IPv6 support
- to map arbitrary usernames to the least used class id
- to minimize the number of map changes when there are a lot of users to sync (not done yet)
- flow fairness (though given your new info below, I think that just got way easier)
- to write the userspace utility in C, for practice

>> - With the new major/minor ID distinction, I’d probably use major for
>> the user and minor for the flow hash?
> 
> Yes. See the latest commit in the tc-adv repo for a man page update explaining it. You can also just set the major ID and let cake do the flow hashing…

Aha, that’s terribly convenient but also means I don’t really need to solve the hashing problem (rats), and will be ripping out some of what I started. :)

>> Another thing I haven’t looked into yet is that when fq_codel is the
>> qdisc, the eBPF action is only called "once in a while” (start of a new
>> flow?) With cake it’s called for every single packet, which is what I
>> expected to happen, but very different behavior.
> 
> Maybe because fq_codel is not splitting gso packets?

Good one, I wonder, because I see it’s not just “new flow”, I seem to see it called again on the same flow if there’s a pause in packets on it for “some time”.


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