[Cake] Same flow 'optimization' did not look correct

Kevin Darbyshire-Bryant kevin at darbyshire-bryant.me.uk
Fri Nov 27 09:33:22 EST 2015

I've been pondering this commit and wonder if we're throwing out baby
with bathwater:


The original code, to paraphrase in something resembling English went:

1. I've just enqueud a packet & Oh sh*t we're over our q_disc buffer
limit, we'd better do something about it, hmmm
2. Whilst we're over this limit, go look through our flows (cake_drop)
and kill something, if that something was in the same flow as the thing
we just enqueued then set a flag 'cos these guys are part of the
problem!  Keep track of how many things we killed.
3 Now we're below the limit and finished killing packets, return back to
our caller - if we killed stuff in the same flow the caller is sending,
then return 'NET_XMIT_CN' (we're congested), else just say 'happy as Larry'

 *//* NET_XMIT_CN is special. It does not guarantee that this packet is
lost. It/*
*/* indicates that the device will soon be dropping packets, or already
*/* some packets of the same priority; prompting us to send less
aggressively. *//*

What I do agree looked odd in the original code was the 'dropped -
same_flow':  We haven't dropped any more or fewer packets just 'cos we
found one or more in 'the same flow'.

-        qdisc_tree_decrease_qlen(sch, dropped - same_flow);  <--????????
+        qdisc_tree_decrease_qlen(sch, dropped);

Incidentally, a search of 'NET_XMIT_CN' turned up

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151127/e23a63b6/attachment-0002.bin>

More information about the Cake mailing list