Re: [Cake] Upstream submission of dual-mode fairness patch

[Georgios Amanakis <gamanakis@gmail.com>]

I was just thinking that getting rid of the decrement of flow->deficit
and tin->deficit when we call cake_advance_shaper() to account for
"ingress" traffic might not be that awful after all. That way, the
shaper logic is unaffected but the fairness logic wouldn't account for
that "ingress traffic" and would yield fairer results. I would love to
hear your thoughts.


On Sun, Mar 3, 2019 at 2:49 PM Pete Heist <pete@heistp.net> wrote:
>
>
> > On Mar 3, 2019, at 8:03 PM, gamanakis@gmail.com wrote:
> >
> > 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:
> >                if (q->rate_flags & CAKE_FLAG_INGRESS) {
> >                        len = cake_advance_shaper(q, b, skb,
> >                                                  now, true);
> > -                       flow->deficit -= len;
> >                        b->tin_deficit -= len;
> >                }
> >                flow->dropped++;
> > ----------8<----------
> >
> >
> > Then the results are:
> >
> > IP1, 1 up:    47.18 mbit/s
> > IP2, 32 up:   46.99
> > IP1, 32 down: 40.98
> > IP2, 1 down:  41.34
>
> Yes, thanks for confirming it, this fix equalizes goodput for me as well, although I think we’re in agreement that nothing should actually change in the end(?)
>
> If so, I think we should document this. If it wasn’t obvious to us right away what was happening, then it probably won’t be obvious to others.
>
> If I don’t hear any objection to this in the next couple days, I’ll submit a pull request to tc-adv for tc-cake.8, if that’s the right place to do it.
>