For the record, I can replicate it now. I also think that this behavior is
expected.
There is a work-around but it seems like an awful hack:
--8<--
diff --git a/sch_cake.c b/sch_cake.c
index 733b897..08e08f4 100644
--- a/sch_cake.c
+++ b/sch_cake.c
@@ -2216,7 +2216,6 @@ retry:
I think it's much simpler to use than tc-filter, BPF or even DSCP bits.
Manipulating DSCP bits seems the simplest of the currently available mechanisms
to classify traffic. Even in this case, fwmarks are essentially simpler.
E.g. if you want to classify outgoing traffic on the LAN interface:
with
> The important thing is that the host_bulk_flow_count values match the
> actual bulk-status and host-reference properties assigned to each flow
> queue. When a hash collision occurs, the bulk-status of the affected flow
> doesn't change but the hosts to which it refers might do. In that case
the
> On the contrary, even if a particular flow is sparse, the relevant quantum
> calculation should involve the number of *bulk* flows attached to the same
> host. Though there is possibly an argument for making it the *sum* of the
> sparse and bulk flows, making it just the sparse ones is wrong.
I
>1: Why is host_load calculated using host_sparse_flow_count instead of
host_bulk_flow_count in cake_enqueue()?
Because the flow for which cake_enqueue() is run is by definition a sparse
one. So the host_load should be adjusted according to the sparse flow count
for the particular host. That's my r
I was having a look at cake's hash code and it seems srchost_hash and
dsthost_hash, as well as the flowkeys in NAT are not calculated in plain
"srchost" or "dsthost" modes. CAKE_FLOW_FLOWS and CAKE_FLOW_HOSTS are both 0
(conditional in line 633) when src/dst-host is set as flow mode. So the code
go
I am currently testing latest net-next with both sch_cake and
nf_conntrack compiled as integrals (Y instead of M). So far it works as
expected (previous build was 4.9.64, sch_cake out-of-tree, and
nf_conntrack as module).
Are there any specific tests you would like me to run?
I am attaching the p
Just finished building, setting both sch_cake and nf_conntrack as
integral succeeds. Setting nf_conntrack as module fails with sch_cake
as integral (makes sense).
I am remote right now and cannot test the newly built kernel, hopefully
I will get it done tonight.
George
On Sat, 2017-11-25 at 17:0
