Treating in and out slightly differently in cake

[dtaht]

After staring at the data a while, also knowing there are details in the extended tc class statistics (4096 queues) we are not presently getting at, I realized there was a small cake mod that made it more possible to correlate in and out post-hoc. It looks to be easy to add (I have already got rid of smoothing and then destructively sampling in my babycake branch, which makes the sawtooths and bandwidth graphs much more accurate) - the idea of using a reversed hash on the other direction of the connection.

so it would hash on dst,dst_port,src,src_port,proto in that case and have a hash consistent with the other direction, when sampled. As for the uses of this, I am not sure, correlating a flow, back to itself would be useful for tracking I think wifi problems, looking for burstiness in that traffic, as one example. Picking out voip and videoconferencing behaviors as distinct from tcp... Also, dealing with hashes is nicely anonymizable... I have looked over urcu, and had a brief chat with the author of it:

He wrote:

To match hashed keys between ingress and egress traffic, I would recommend to have a look at the rcu lock-free hash table
upstream in the liburcu project, because I don't think you need an
ordered set.

Problem B) Keep timestamp-ordered records of your traffic for later
post-processing. For this, I would recommend to have a look at the
LTTng-UST project (which I maintain), which is specialized for
high-throughput userspace tracing through per-core ring buffers. Its
counterpart to read the binary traces at post-processing is Babeltrace.

[dtaht]

#159

#183

WIP:

https://github.com/dtaht/sch_cake/tree/babycake

[dtaht]

Just to remain cynical about the need for affinity and better bin-packing, referring to this closed bug: #127

[dtaht]

I am not sure if the binpacking makes total sense or not at this point. 1) I think that in/out traffic for the same circuit should land on the same cpu. Or perhaps they shouldnt. I dont know. 2) We have discussed binpacking based more on an assumption that 30 10Mbit subscribers are more likely than one 300Mbit subscriber to need more bandwidth. 3) The current binpacking algo (I think) puts the lightest load on the last CPU, where given how much stuff defaults to cpu 0, the tree should be inverted.

[dtaht]

I would like a sqm_in and sqm_out variable, overriding the sqm variable if needed.

[dtaht]

@rchac I would like sqm_in and sqm_out, and also, we need to tune cake below 4Mbits.