[Cake] [Ecn-sane] l4s kernel submission

[Dave Taht]

On Thu, Oct 14, 2021 at 3:10 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
> Dave Taht <dave.taht at gmail.com> writes:
>
> > On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> >>
> >> Dave Taht <dave.taht at gmail.com> writes:
> >>
> >> > weirdly enough, my gmail account has not received anything from netdev
> >> > since oct 11.
> >>
> >> You're not alone in that:
> >> https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t
> >
> > ok. One of these years I'll go back to running my own email server
> > full time.
>
> You can also subscribe to Linux lists by importing the mails from Lore,
> as one of the replies in the thread above pointed out. Been meaning to
> switch to that myself, but haven't gotten around to it yet...

I attempted to subscribe again, nothing happened.

figuring out lore... is too much work for today. I'd rather hammer
small things into oblivion on my boat.

please feel free to pass along my comments and the sce teams findings
into that thread.

>
> >> > yes, i think fq_codel will be better, and even the proposed
> >> > too-shallow threshold will make for less of a dent on the internet.
> >> >
> >> > still... I do wish I'd seen this earlier.
> >>
> >> Earlier? You forwarded the patch hours after it was posted...
> >
> > I have a daily search for fq_codel, bufferbloat, etc. I have noticed
> > lately that some mailing list traffic from us is being indexed again.
> > I wish I knew why our lists were not indexed by google.
> >
> > Anyway, lacking being on that thread, it's currently impossible to
> > reply.
>
> The Lore page contains instructions for various ways of replying even
> without having the original email message in your mailbox. It's at the
> bottom...
>
> > That said, the l4s fq_codel patch is intrinsically fair, which is
> > vastly superior to the dualpi approach.
>
> Yup, I agree it's better, but I don't like baking in the ECT(1)
> semantics to UAPI. I suggested a filter-based approach which I'm
> currently discussing with Eric on that thread as you might have noticed :)
>
> -Toke



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC