On Thu, Sep 29, 2016 at 10:03 PM, Dave Taht wrote:
> Now... as for the other stuff in that blog entry (I never got around
> to writing parts II and III), I am curious as to your raw PPS with
> small packets presently, and if you've figured out how to apply
> fq_codel internally yet? :-P
I haven't
On Thu, Sep 29, 2016 at 12:05 PM, Jason A. Donenfeld wrote:
> On Thu, Sep 29, 2016 at 9:03 PM, Dave Taht wrote:
>> that + 1 was clever. I think you are done... and I should go change the
>> blog. :)
>
> Yea I like tricks like that. Anytime you have a range of values in the
> middle, you can just
On Thu, Sep 29, 2016 at 9:03 PM, Dave Taht wrote:
> that + 1 was clever. I think you are done... and I should go change the blog.
> :)
Yea I like tricks like that. Anytime you have a range of values in the
middle, you can just add, modulo, and check the end.
_
that + 1 was clever. I think you are done... and I should go change the blog. :)
On Thu, Sep 29, 2016 at 11:59 AM, Jason A. Donenfeld wrote:
> On Thu, Sep 29, 2016 at 8:19 PM, Dave Taht wrote:
>> I think the correct behavior here is to only set ce on the inner
>> packet if the inner packet is ma
On Thu, Sep 29, 2016 at 8:19 PM, Dave Taht wrote:
> I think the correct behavior here is to only set ce on the inner
> packet if the inner packet is marked as ecn capable.
IP_ECN_set_ce already does this. It exits early if it isn't already
ECT(1) or ECT(0):
static inline int IP_ECN_set_ce(struct
On Thu, Sep 29, 2016 at 10:50 AM, Jason A. Donenfeld wrote:
> Hey Dave,
>
> I'm back! Catching up on the backlog now. You wrote in your blog post:
Welcome back!
I got distracted also. See "TCP BBR".
I have no idea how sch_fq + pacing fits into your design, either.
>> In a day, the author (whil
Hey Dave,
I'm back! Catching up on the backlog now. You wrote in your blog post:
> In a day, the author (while on a plane!) tossed off an ecn encapsulation
> implementation (it worked! but it’s not currently as modern RFC compliant as
> it should be),
What part of it deviates from the RFC preci
