> On Apr 6, 2017, at 2:14 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
>> Pete Heist <peteheist@gmail.com> writes:
>> but I’m still a little confused. Is fq_codel actually a classful
>> qdisc?
> 
> Yup. The hash buckets are the classes, basically. You can get per-flow
> stats by doing `tc -s class show dev eth0` (only works when a flow has
> built a queue).

I see now, never knew that… :)

>> I get the part about matching with tc-filter and the u32 selector (as
>> intuitive as that is :), but am not sure of the action the filter
>> needs to take. However, I do see the example towards the bottom of the
>> tc-u32 man page where a hash table is created and filters move packets
>> into the right buckets. Perhaps it will be eventually decipherable
>> from this… :)
> 
> The filter classifies a packet into a class. The 'minor number' of this
> is the queue number (so needs to be less than the number of flows you
> configured for fq_codel - 1024 by default).

It’s clearer to me now how to split traffic by member (using their MAC addresses- and by clear I mean not totally clear yet but should become clear :) but to get both per-member and per-flow hashing together isn’t as clear yet (which I think is what Cake’s dual-srchost does). Maybe a separate table per-member could be created. ‘u32’ looks arcane, but flexible...