[Cake] cake's ack-filter vs GSO

[Cake] cake's ack-filter vs GSO

[Dave Taht]

It has been years since I looked at cake's code.

Does anyone remember why we do not ack-filter a gso-split?

https://github.com/dtaht/sch_cake/blob/master/sch_cake.c#L1901


-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

Re: [Cake] cake's ack-filter vs GSO

[Jonathan Morton]

> On 18 Feb, 2024, at 2:01 am, Dave Taht via Cake <cake@lists.bufferbloat.net> wrote:
> 
> Does anyone remember why we do not ack-filter a gso-split?

That may actually be unintentional.  The original code self-recursed, IIRC, so individual segments would then go through the non-gso-split path.  At some point we inlined it for efficiency.

The thing to try might be to copy the relevant code (both the search and the drop) into the gso-split path and see if anything breaks, and if the ack-dropping statistics tend to increase.

 - Jonathan Morton

Re: [Cake] cake's ack-filter vs GSO

[Toke Høiland-Jørgensen]

Dave Taht via Cake <cake@lists.bufferbloat.net> writes:

> It has been years since I looked at cake's code.
>
> Does anyone remember why we do not ack-filter a gso-split?

Because a GSO packet cannot be a pure ACK, so it wouldn't be filtered
anyway...

-Toke

Re: [Cake] cake's ack-filter vs GSO

[Dave Taht]

On Sun, Feb 18, 2024 at 8:37 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht via Cake <cake@lists.bufferbloat.net> writes:
>
> > It has been years since I looked at cake's code.
> >
> > Does anyone remember why we do not ack-filter a gso-split?
>
> Because a GSO packet cannot be a pure ACK, so it wouldn't be filtered
> anyway...

But a GRO packet can, and most likely IS a pure ack packet train that
could and should be thinned. I think. Yes?

Anyway, I put in for a small grant a few months ago with NLNET on this
(and keep hoping that somewhere out there, there are more orgs using
cake willing to throw in? I mean there are hundreds now! Can anyone
reach out to them?)

It might be approved in a month or so - but it also had scope in
looking at transports and the BSDs, and I keep hoping to somehow find
enough resources to have a project with 3 core folk running at it part
time for 2 years.

https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit

Elsewhere a volunteer started some work on validating the fq_codel
implementations of openbsd and freebsd. The results are interesting!
The "wrong" openbsd version with a 400 count cap does not behave much
differently from the one with the pure newton invsqrt approximation in
the tests so far. Can anyone suggest tests to exercise it?

Do I have the energy to write them up yet? No. I might start yet
another mailing list to discuss it. My long term hope is to gain
enough experience, somehow get cake ported over to those OSes
eventually, but I would settle for just quieting the noise in the
opnsense world.

I am trying to have a BQL discussion on the netdev list also, about
virtio-net...

Maybe this presentation will gain traction:
https://www.youtube.com/watch?v=rWnb543Sdk8&t=2603s


>
> -Toke



--
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos

Re: [Cake] cake's ack-filter vs GSO

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> On Sun, Feb 18, 2024 at 8:37 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Dave Taht via Cake <cake@lists.bufferbloat.net> writes:
>>
>> > It has been years since I looked at cake's code.
>> >
>> > Does anyone remember why we do not ack-filter a gso-split?
>>
>> Because a GSO packet cannot be a pure ACK, so it wouldn't be filtered
>> anyway...
>
> But a GRO packet can, and most likely IS a pure ack packet train that
> could and should be thinned. I think. Yes?

Erm, no, because those would have header differences and so wouldn't be
combined into a single GRO packet...

-Toke

Re: [Cake] cake's ack-filter vs GSO

[Dave Taht]

My memory about all this stuff is extremely scrambled by the mvneta
driver which ws the first thing that drove me to consider GSO
splitting in the first place.

That evolved significantly. I also remember XMIT_more costing us more
bandwidth than it gained, on the wndr3800, due to eating more cpu or
icache. Then there was the change in how inbound skbs were processed
overall, and innumerable attempts to remove locks from pfifo_fast, and
... ghu knows what else has changed. How does packet pacing affect
things? How much BBRv3 buffers?

I am no longer certain of anything. I am pretty sure, however, that
vikings were not black.

https://gizmodo.com/google-anti-woke-babies-gemini-black-vikings-1851275422

I asked the latest AIs for summaries as to what fq_codel does, what
products it is in, and it was slightly wrong in all cases.

What products have fq_codel in them?" was pretty good.

It just missed apple.

Asking gemini again:

"Is the pie aqm better than fq_codel? How do both compare to CAKE" was also fun.

It generated a really nice table. And made my skin itch at the inaccuracies.

Is the pie aqm better than fq_codel? How do both compare to CAKE?

On Fri, Feb 23, 2024 at 11:39 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> writes:
>
> > On Sun, Feb 18, 2024 at 8:37 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> Dave Taht via Cake <cake@lists.bufferbloat.net> writes:
> >>
> >> > It has been years since I looked at cake's code.
> >> >
> >> > Does anyone remember why we do not ack-filter a gso-split?
> >>
> >> Because a GSO packet cannot be a pure ACK, so it wouldn't be filtered
> >> anyway...
> >
> > But a GRO packet can, and most likely IS a pure ack packet train that
> > could and should be thinned. I think. Yes?
>
> Erm, no, because those would have header differences and so wouldn't be
> combined into a single GRO packet...
>
> -Toke



-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos